From mailman-owner@lists.bell-labs.com Mon May 1 05:13:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22613 for ; Mon, 1 May 2000 05:13:39 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 32E574452D for ; Mon, 1 May 2000 05:06:06 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: sip-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000501090606.32E574452D@lists.bell-labs.com> Date: Mon, 1 May 2000 05:06:06 -0400 (EDT) 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@lists.ietf.org From sip-admin@lists.bell-labs.com Mon May 1 10:31:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27132 for ; Mon, 1 May 2000 10:31:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9EA2744338; Mon, 1 May 2000 10:26:10 -0400 (EDT) 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 34A8244336 for ; Mon, 1 May 2000 10:26:08 -0400 (EDT) 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 KAA08950; Mon, 1 May 2000 10:31:13 -0400 (EDT) Message-ID: <390D9531.B81CA74D@cs.columbia.edu> Date: Mon, 01 May 2000 10:31:13 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , sip@lists.bell-labs.com References: <3908D34E.58792A22@dynamicsoft.com> <3908DE4E.AACD120C@cs.columbia.edu> <3908E2FD.A74721BD@dynamicsoft.com> <3908E6A9.693424B8@cs.columbia.edu> <3908E99C.BF91B6E6@dynamicsoft.com> <3908F193.7CC145CF@cs.columbia.edu> <390922BC.8AA45A0B@dynamicsoft.com> <390A0033.691D4335@dynamicsoft.com> <390A1C1C.FC65039D@cs.columbia.edu> <390D055B.2B1CEAE9@dynamicsoft.com> <390D7CFE.9FB50CC7@cs.columbia.edu> <390D8F1F.EE1C1F4E@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Case sensitivity Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I believe we need to take a closer look at the annoying topic of case-sensitivity (or not). A rough summary is: Method CS Header field name CI Any Accept-* token CI (includes compression, language, media type) SDP encoding name CI (such as PCMU, L16, etc.) URL mostly CS (except host) Some additional issues: (1) Parameters like ;level or ;q in Accept. Are ;LEVEL and ;Q the same thing? RFC 2616 seems to indicate this: 3.7: The type, subtype, and parameter attribute names are case- insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. 2.1 Augmented BNF "literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive. [This would apply to most enumerated parameters, like "hop" or "hide" tokens in our case, or the "action" tokens in Contact or Content-Disposition or the Priority values.] My general impression is that HTTP/1.x seems to treat tokens not enclosed in quotation marks as CI and anything in quotation marks as CS, with URLs as a separate matter. (2) HTTP-date (and, thus, rfc1123-date) is case sensitive. Any other cases? -- 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 May 1 10:43:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27302 for ; Mon, 1 May 2000 10:43:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58D464434A; Mon, 1 May 2000 10:38:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id B44B544341 for ; Mon, 1 May 2000 10:38:13 -0400 (EDT) Received: by dnspri.npac.com; id JAA11462; Mon, 1 May 2000 09:43:19 -0500 (CDT) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma011338; Mon, 1 May 00 09:42:39 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 1 May 2000 09:42:27 -0500 Message-ID: From: James Yu To: "'James Kempf'" Cc: sip@lists.bell-labs.com, "'SIGTRAN@STANDARDS.NORTELNETWORKS.COM'" Subject: RE: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol Date: Mon, 1 May 2000 09:41:52 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com James, Your question can be addressed by sigtran - SS7 transport over IP. There are a few adaptation layers to choose including the newly proposed SUA (for SCCP users such as IS-41). James Yu > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Eng.Sun.COM] > Sent: Friday, April 14, 2000 5:59 PM > To: sip@lists.bell-labs.com > Cc: James.Kempf@Eng.Sun.COM > Subject: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol > > > I'm working on a design for replacing the IS-41 North > American cellular > signalling protocol with IP protocols. I had a couple of > questions about > how the SIP INFO method, or potentially another SIP method, might > be used. > > 1) In the introduction to draft-ietf-sip-info-method-03.txt, exchange > of radio signal strength information is explicitly mentioned as > an application of the SIP INFO method. The HandoffMeasurementRequest > and HandoffMeasurementRequest2 messages in IS-41 are sent by > the anchor > Mobile Switching Center (MSC) to a potential serving MSC to > obtain information > about the signal strength of a Mobile Station (MS) in order > to determine > if the potential serving MSC is a better candidate for handling the > mobile's call (called "hard handoff" in cellular jargon). > They could be > replaced with a SIP INFO method. There are three problems: > > a) The radio information is always solicited by the anchor MSC, > and from the ID, the SIP INFO method seems like it is > sent unsolicted. I suppose one could come up with two INFO > methods, one to solicit the radio information and one to > return it, but this seems like a hack somehow. > > b) In the ID, it explicitly states that the INFO method is > only applicable when there is a call in progress. Problem is, > there isn't a call in progress between the anchor MSC and > the serving MSC, that's why the anchor MSC is soliciting > the radio quality information in the first place. > > c) The INFO method seems like it is meant to be sent between > SIP UAC's, while the HandoffMeasurementRequest(2) methods > are primarily designed to be sent between network elements. > A SIP replacement would probably be sent between the > last hop SIP > proxies acting as Call Agents (CAs) for the call, which replaces > the MSC in an all IP network. > > 2) There are a bunch of IS-41 messages that involve transmitting > feature or other information between the MS's Home Location > Register (HLR) and the MS. These are initiated by either the serving > MSC or the HLR. Examples are InformationDirective, which is used > by the HLR to provide notifications to an idle MS, and FeatureRequest, > which sends particular features to a potentially idle MS (features > being things like messages or playing particular tones). Again, these > seem like candidates to replace with the SIP INFO message, but > the potential lack of any call in progress would prohibit that. > > The alternative I could see would be establishing a session in order > to then send the information via the INFO method, but that seems like > overkill. And in the case of HandoffMeasurementRequest(2), the > message isn't intended for a SIP UAC anyway. > > Maybe SIP is the wrong protocol to consider, since it is dedicated > to setting up and maintaining sessions, and not to exchanging > information > between network elements or between network elements and terminals? > > Can anybody provide some guidance? > > jak > > > > _______________________________________________ > 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 May 1 12:08:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29241 for ; Mon, 1 May 2000 12:08:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A73D4433A; Mon, 1 May 2000 12:03:31 -0400 (EDT) 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 A8C1D44336 for ; Mon, 1 May 2000 12:03:28 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 1 May 2000 10:59:12 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KB3VMFAK; Mon, 1 May 2000 11:59:09 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H3K89490; Mon, 1 May 2000 11:59:08 -0400 Message-ID: <390DAA62.A172FB48@americasm01.nt.com> Date: Mon, 01 May 2000 12:01:38 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Jonathan Rosenberg , Sip Mail List Subject: Re: [Fwd: [SIP] Sip URL and escaped characters. RFC 2543 Section 2] References: <39092496.2C0ABAE6@dynamicsoft.com> <390B2BE1.F0866994@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------19A162171A882F5FE670CDEC" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------19A162171A882F5FE670CDEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I hesitate to wade into this because things tend to get somewhat philosophical, but I think there are some important underlying design issues. In any protocol (or grammar) design, there's syntax and semantics. Unfortunately, they're not always cleanly separated in the specification. As noted, ABNF is pretty good notation for syntax but really wasn't designed to express semantics. Unfortunately, designers often try to capture semantics in ABNF because it's a concise and formal way of doing so *when it works*. But it's a slippery slope, and you often wind up with an ambiguous or unusable syntactic specification as a result. The URL parameter is a good example of this. It appears that the "other-param" rule completely captures the syntax. The various other parameter rules (transport-param, user-param, etc.) really capture semantics rather than syntax. Now if all parameter names and values were enumerated, these "enumerating" rules would capture both syntax and semantics and "other-param" wouldn't be necessary. So presumably it was included to account for yet unforeseen future parameters where the syntax needs to be generically specified, but the semantics (including names and values) aren't yet known. However in doing so, the semantic checking is eliminated; "transport=fuddle" is perfectly valid syntax, so the apparent semantic constraint implied by the transport-param rule has been lost. Is this a transport parameter with an illegal value or a yet to be defined "other" parameter. A syntactic or semantic violation, or no violation at all? My own preference would be to define a core SIP syntax which is captured in the ABNF. (ABNF does have a few problems, but that's another discussion.) The current grammar and any future extensions should be parsable using this syntax specification, because there's no attempt to define semantics. Barring a formal semantic notation, all semantics is captured in the text as is currently done, e.g., the text describing the From header states: The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers" elements. A server that receives a SIP-URL with these elements removes them before further processing. Note that the semantics includes not only legal parameter names and values in that context, but what should occur when the "semantics" is violated. So I think a more rigorous syntactic definition of SIP which is separate from semantics would lead to a more concise core syntax, a more understandable spec, and possibly better implementation designs, since there would be less tendency to enforce semantic constraints in parsers which would get re-written whenever an extension is added. I note that SIP is no better or worse than many of the other IETF protocols in this respect. (Computer language designers seem to have done a better job on this probably because there is a much clearer separation of syntax and semantics in their domain.) Rick Workman Nortel Networks Ottawa Henning Schulzrinne wrote: > Maybe time to summarize and see if there's an issue left: > > - The host part of the URL cannot contain %, either as itself or as an > escape mechanism: > > host = hostname | IPv4address > hostname = *( domainlabel "." ) toplabel [ "." ] > domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum > toplabel = alpha | alpha *( alphanum | "-" ) alphanum > alphanum = alpha | digit > > - For "token" elements in URLs, this is a bit tricky, since we have two > escape mechanisms that are intersecting: > > (1) the normal token definition, i.e., any letter, digit, and a large > number of symbols (-, #, $, &, %, ^, *, _, +, |, ~, ') > > (2) the rules for URLs, where some of these characters (&, +) are > reserved and thus need to be escaped if there's the possibility of > confusion with a separator. As far as I can tell, neither of them are > syntactically relevant for SIP URLs in this context (the & is only used > to separate 'header' items), so neither of them would need to be > escaped. > > Thus, it might be better to define > > other-param = pname [ "=" pvalue ] > > pname = 1*tokenchar > pvalue = 1*tokenchar | quoted-string > tokenchar = alphanum | escaped | "!" | "'" | "*" | "." > | "^" | "_" | "~" | "|" | "%" | "-" | "#" | "/" | ":" | "@" > | "&" | "+" | "$" > > (since "," is not valid in token, I didn't include it. Any that I'm > missing?) > > Here, escaped can only refer to the legal characters (alphanum and the > others) to maintain "tokenness", but I can't express this in the BNF. > However, in practice this is not a problem except for spec-writers since > the pname and pvalue tokens have to be drawn from an enumeration, so > that most character combinations are invalid simply because they are not > valid parameter names. > > - To make matters slightly more confusing, we do have a different > potential problem, namely the " in the quoted string. The <"> is a > "delims" character and thus must be escaped (RFC 2396, pg. 9/10). One > could argue that it only needs to be escaped if there's a possibility > for confusion, e.g., on a web page or if the URL appears in a quoted > string. However, either should be accepted by the parser. > > - In URLs, %hex hex (where allowed) is always interpreted as an escape > mechanism. It is mechanically translated to the equivalent character, > while maintaining its distinct identity as a non-separator (if it could > be treated as such). Thus, > > foo%40bar@host.com > > can't just be translated into foo@bar@host.com and then be parsed, since > the result would not be as expected. This is not fundamentally different > from other escape mechanisms for delimiters, like \" or "". > > Thus, one should *first* split the URL into components and then > translate those parts where escaping is possible (which is pretty much > anywhere except in scheme and host). > > - As was pointed out, BNF specifies syntax. It cannot express certain > things, including > . restrictions on ordering (an | does not imply that the elements > have to appear in order) > . any restriction on duplication > . the role of identifiers or restrictions on their names (e.g., "int > int" may be legal in a BNF specification but the compiler may still > complain) > > For details, see for example, pg. 172 of Aho/Sethi/Ullman: > > "Certain constraints on the input, such as the requirement that > identifiers be declared before they are used, cannot be described by a > context-free grammar." > > If there are places where the grammar needs to be tightened up, let me > know. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------19A162171A882F5FE670CDEC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I hesitate to wade into this because things tend to get somewhat philosophical, but I think there are some important underlying design issues. In any protocol (or grammar) design, there's syntax and semantics. Unfortunately, they're not always cleanly separated in the specification. As noted, ABNF is pretty good notation for syntax but really wasn't designed to express semantics. Unfortunately, designers often try to capture semantics in ABNF because it's a concise and formal way of doing so *when it works*. But it's a slippery slope, and you often wind up with an ambiguous or unusable syntactic specification as a result.

The URL parameter is a good example of this. It appears that the "other-param" rule completely captures the syntax. The various other parameter rules (transport-param, user-param, etc.) really capture semantics rather than syntax. Now if all parameter names and values were enumerated, these "enumerating" rules would capture both syntax and semantics and "other-param" wouldn't be necessary. So presumably it was included to account for yet unforeseen future parameters where the syntax needs to be generically specified, but the semantics (including names and values) aren't yet known. However in doing so, the semantic checking is eliminated; "transport=fuddle" is perfectly valid syntax, so the apparent semantic constraint implied by the transport-param rule has been lost. Is this a transport parameter with an illegal value or a yet to be defined "other" parameter. A syntactic or semantic violation, or no violation at all?

My own preference would be to define a core SIP syntax which is captured in the ABNF. (ABNF does have a few problems, but that's another discussion.) The current grammar and any future extensions should be parsable using this syntax specification, because there's no attempt to define semantics. Barring a formal semantic notation, all semantics is captured in the text as is currently done, e.g., the text describing the  From header states:

The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers" elements. A server that receives a SIP-URL with these elements removes them before further processing.

Note that the semantics includes not only legal parameter names and values in that context, but what should occur when the "semantics" is violated.

So I think a more rigorous syntactic definition of SIP which is separate from semantics would lead to a more concise core syntax, a more understandable spec, and possibly better implementation designs, since there would be less tendency to enforce semantic constraints in parsers which would get re-written whenever an extension is added. I note that SIP is no better or worse than many of the other IETF protocols in this respect. (Computer language designers seem to have done a better job on this probably because there is a much clearer separation of syntax and semantics in their domain.)

Rick Workman
Nortel Networks
Ottawa

Henning Schulzrinne wrote:

Maybe time to summarize and see if there's an issue left:

- The host part of the URL cannot contain %, either as itself or as an
escape mechanism:

host          = hostname | IPv4address
hostname      = *( domainlabel "." ) toplabel [ "." ]
domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel      = alpha | alpha *( alphanum | "-" ) alphanum
alphanum      = alpha | digit

- For "token" elements in URLs, this is a bit tricky, since we have two
escape mechanisms that are intersecting:

  (1) the normal token definition, i.e., any letter, digit, and a large
number of symbols (-, #, $, &, %, ^, *, _, +, |, ~, ')

  (2) the rules for URLs, where some of these characters (&, +) are
reserved and thus need to be escaped if there's the possibility of
confusion with a separator. As far as I can tell, neither of them are
syntactically relevant for SIP URLs in this context (the & is only used
to separate 'header' items), so neither of them would need to be
escaped.

Thus, it might be better to define

other-param = pname [ "=" pvalue ]

pname     = 1*tokenchar
pvalue    = 1*tokenchar | quoted-string
tokenchar = alphanum | escaped | "!" | "'" | "*" | "."
            | "^" | "_" | "~" | "|" | "%" | "-" | "#" | "/" | ":" | "@"
| "&" | "+" | "$"

(since "," is not valid in token, I didn't include it. Any that I'm
missing?)

Here, escaped can only refer to the legal characters (alphanum and the
others) to maintain "tokenness", but I can't express this in the BNF.
However, in practice this is not a problem except for spec-writers since
the pname and pvalue tokens have to be drawn from an enumeration, so
that most character combinations are invalid simply because they are not
valid parameter names.

- To make matters slightly more confusing, we do have a different
potential problem, namely the " in the quoted string. The <"> is a
"delims" character and thus must be escaped (RFC 2396, pg. 9/10). One
could argue that it only needs to be escaped if there's a possibility
for confusion, e.g., on a web page or if the URL appears in a quoted
string. However, either should be accepted by the parser.

- In URLs, %hex hex (where allowed) is always interpreted as an escape
mechanism. It is mechanically translated to the equivalent character,
while maintaining its distinct identity as a non-separator (if it could
be treated as such). Thus,

foo%40bar@host.com

can't just be translated into foo@bar@host.com and then be parsed, since
the result would not be as expected. This is not fundamentally different
from other escape mechanisms for delimiters, like \" or "".

Thus, one should *first* split the URL into components and then
translate those parts where escaping is possible (which is pretty much
anywhere except in scheme and host).

- As was pointed out, BNF specifies syntax. It cannot express certain
things, including
  . restrictions on ordering  (an | does not imply that the elements
have to appear in order)
  . any restriction on duplication
  . the role of identifiers or restrictions on their names (e.g., "int
int" may be legal in a BNF specification but the compiler may still
complain)

  For details, see for example, pg. 172 of Aho/Sethi/Ullman:

  "Certain constraints on the input, such as the requirement that
identifiers be declared before they are used, cannot be described by a
context-free grammar."

If there are places where the grammar needs to be tightened up, let me
know.

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

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


  --------------19A162171A882F5FE670CDEC-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 1 12:12:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29362 for ; Mon, 1 May 2000 12:12:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEAB14433A; Mon, 1 May 2000 12:06:51 -0400 (EDT) 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 4F9CD44336 for ; Mon, 1 May 2000 12:06:49 -0400 (EDT) Received: from imop.cisco.com (localhost [127.0.0.1]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA20200; Mon, 1 May 2000 09:11:59 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAA06970; Mon, 1 May 2000 09:09:19 -0700 (PDT) Message-Id: <4.2.0.58.20000501085919.00cf2100@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 01 May 2000 09:11:15 -0700 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: [SIP] mwi in SIP: supplying waiting message lists Cc: Ilya Slain , sip@lists.bell-labs.com, binguyen@cisco.com In-Reply-To: <3909356B.3045BF7F@dynamicsoft.com> References: <20000423170750.2723.qmail@web219.mail.yahoo.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan, I took a good look at IMAP, POP, and VPIM for message waiting. The models were too different to use, as Henning begins to hint. The only thing that survived serious scrutiny was the mailbox status definitions used in IMAP. I proposed an XML-based representation of mailbox summary inside Cisco. Ilya proposed a more-simple text-based representation of the same information, which is what you see below. We felt that the UA should have access to a summary so it could display things like: "You have 2 new, and 5 old voice messages; and 1 old fax message." It would be very nice to have some proposed solution for message waiting. thanks, -rohan message status borrowed from IMAP: > > U = UNTOUCHED > > S = SKIPPED > > F = FLAGGED > > R = READ > > A = ANSWERED > > D = DELETED thanks, -rohan At 11:53 PM 4/27/00 , Jonathan Rosenberg wrote: >Message waiting has come up numerous times. I agree we should have a >solution based on a subscribe/notify method. Just to note, I do believe >there are other ways to do this that can make use of other existing >protocols. For systems that use email-based voicemail storage (like >VPIM), IMAP may actually be the appropriate protocol for message >waiting. I accept that IMAP is gross overkill for systems that just want >voicemail only message waiting lamps, so something a little more focused >would be useful. > >As pointed out in another thread, the described mechanism of enumerating >events in SUBSCRIBE is too restrictive and not compatible with pint. >Rather than attacking these bit at a time, I think it would be >tremendously valuable to list the general set of events and state >associated with SIP communications systems that one might wish to >subscribe to. This will help us figure out the set of things we might >like to build in to some set of "sip presence subscription documents", >which are carried in SUBSCRIBE messages to indicate what is being >subscribed to. > >-Jonathan R. > >Ilya Slain wrote: > > > > There has recently been some discussion on the way to > > do message waiting indication (mwi) using SUBSCRIBE/ > > NOTIFY SIP extensions. However, I am not aware of > > any proposals to for specifying waiting message list > > summary, supplied in mwi NOTIFY message. In other > > words, there is no proposed way to supply the summary > > of messages being available in the voice mail system. > > > > So I would like to submit a brief sample proposal to > > do > > message waiting indication with message summary using > > SIP > > SUBSCRIBE/NOTIFY. This is based on the recent > > SUBSCSRIBE/ > > NOTIFY IETF draft: > > > http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt > > > > The main purpose of this proposal is to start the > > discussion > > on the topic with the aim of eventually submitting an > > Inf. Draft. > > > > 1. Subscription > > ---------------- > > Event field specifies "mwi" field (message waiting > > indication). > > There is no message body. > > > > SUBSCRIBE ... > > To: ... > > From: ... > > Call-ID: ... > > CSeq: ... > > Contact: ... > > Expires: ... > > Event: mwi > > Content-Length: 0 > > > > 2. Notification > > ----------------- > > Event field specifies "mwi". > > Message body specifies the message summary. > > > > NOTIFY > > To: ... > > From: ... > > Call-ID: ... > > CSeq: ... > > Contact: ... > > Expires: ... > > Event: mwi > > Content-Type: application/um > > Content-Length: 148 > > > > VOICEMAIL: ; U:n1/n2; S:n1/n2; > > F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2 > > EMAIL: ; U:n1/n2; S:n1/n2; > > F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2 > > FAX: ; U:n1/n2; S:n1/n2; > > F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2 > > VIDEO: ; U:n1/n2; S:n1/n2; > > F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2 > > > > where TOTAL_MESSAGES, n1, n2 are integers > > U = UNTOUCHED > > S = SKIPPED > > F = FLAGGED > > R = READ > > A = ANSWERED > > D = DELETED > > > > For example: > > voicemail: 10; U:3/1; S:1/0; F:0/0; R:5/2; A:1/0; > > D:0/0 > > where U: 3/1 indicates that there are 3 untouched > > messages, 1 of which is urgent. > > > > More formal grammar for the application/um message > > body: > > > > application_um_message_body = message_summary_list > > message_summary_list = message_summary "\n" > > message_summary_list | NULL > > message_summary = message_type ": " total_messages "; > > " typed_summary_list > > message_type = "VOICEMAIL" | "EMAIL" | "FAX" | "VIDEO" > > total_messages = INTEGER > > typed_summary_list = typed_summary ";" > > typed_summary_list | NULL > > typed_summary = type ":" number_of_messages "/" > > number_of_urgent_messages > > type = "U" | "S" | "F" | "R" | "A" | "D" > > number_of_messages = INTEGER > > number_of_urgent_messages = INTEGER > > > > > ______________________________________________________________________________ > > > > Ilya Slain || || > > Cisco Systems, Inc. > > Technology Center .||. .||. > > Building 9 > > .||||. .||||. > > 170 West Tasman Drive > > Tel: 408.527.9446 ...||||||||..||||||||... > > San Jose, CA 95134 > > Fax: 408.527.1221 C i s c o S y s t e m s > > E-Mail: islain@cisco.com > > > ____________________________________________________________________________ > > > > __________________________________________________ > > Do You Yahoo!? > > Send online invitations with Yahoo! Invites. > > http://invites.yahoo.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (732) 741-4778 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >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 Mon May 1 13:13:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00579 for ; Mon, 1 May 2000 13:13:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0E994433A; Mon, 1 May 2000 13:08:21 -0400 (EDT) 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 3AE7E44336 for ; Mon, 1 May 2000 13:08:19 -0400 (EDT) Received: from imop.cisco.com (localhost [127.0.0.1]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA28069; Mon, 1 May 2000 10:13:29 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAA07605; Mon, 1 May 2000 10:10:49 -0700 (PDT) Message-Id: <4.2.0.58.20000501093054.00cefdf0@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 01 May 2000 10:11:45 -0700 To: Henning Schulzrinne From: Rohan Mahy Subject: Re: [Fwd: [SIP] Sip URL and escaped characters. RFC 2543 Section 2] Cc: Jonathan Rosenberg , Sip Mail List In-Reply-To: <390B2BE1.F0866994@cs.columbia.edu> References: <39092496.2C0ABAE6@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I just want to make sure that we can handle/describe the escaping of a nested monster such as this: (sorrry for the wrapping at hyphens) &Request-Disposition=parallel>"> this would be a SIP URI inside an HTML page, that asks userA's "Butler" (wherever he/she might be) to call (presumably userA's) cell phone. this particular example may be a bit contrived, but i can come up with legitimate uses of this kind of functionality. thanks, -rohan At 11:37 AM 4/29/00 , Henning Schulzrinne wrote: >Maybe time to summarize and see if there's an issue left: > >- The host part of the URL cannot contain %, either as itself or as an >escape mechanism: > >host = hostname | IPv4address >hostname = *( domainlabel "." ) toplabel [ "." ] >domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum >toplabel = alpha | alpha *( alphanum | "-" ) alphanum >alphanum = alpha | digit > >- For "token" elements in URLs, this is a bit tricky, since we have two >escape mechanisms that are intersecting: > > (1) the normal token definition, i.e., any letter, digit, and a large >number of symbols (-, #, $, &, %, ^, *, _, +, |, ~, ') > > (2) the rules for URLs, where some of these characters (&, +) are >reserved and thus need to be escaped if there's the possibility of >confusion with a separator. As far as I can tell, neither of them are >syntactically relevant for SIP URLs in this context (the & is only used >to separate 'header' items), so neither of them would need to be >escaped. > >Thus, it might be better to define > >other-param = pname [ "=" pvalue ] > >pname = 1*tokenchar >pvalue = 1*tokenchar | quoted-string >tokenchar = alphanum | escaped | "!" | "'" | "*" | "." > | "^" | "_" | "~" | "|" | "%" | "-" | "#" | "/" | ":" | "@" >| "&" | "+" | "$" > >(since "," is not valid in token, I didn't include it. Any that I'm >missing?) > >Here, escaped can only refer to the legal characters (alphanum and the >others) to maintain "tokenness", but I can't express this in the BNF. >However, in practice this is not a problem except for spec-writers since >the pname and pvalue tokens have to be drawn from an enumeration, so >that most character combinations are invalid simply because they are not >valid parameter names. > >- To make matters slightly more confusing, we do have a different >potential problem, namely the " in the quoted string. The <"> is a >"delims" character and thus must be escaped (RFC 2396, pg. 9/10). One >could argue that it only needs to be escaped if there's a possibility >for confusion, e.g., on a web page or if the URL appears in a quoted >string. However, either should be accepted by the parser. > > >- In URLs, %hex hex (where allowed) is always interpreted as an escape >mechanism. It is mechanically translated to the equivalent character, >while maintaining its distinct identity as a non-separator (if it could >be treated as such). Thus, > >foo%40bar@host.com > >can't just be translated into foo@bar@host.com and then be parsed, since >the result would not be as expected. This is not fundamentally different >from other escape mechanisms for delimiters, like \" or "". > >Thus, one should *first* split the URL into components and then >translate those parts where escaping is possible (which is pretty much >anywhere except in scheme and host). > >- As was pointed out, BNF specifies syntax. It cannot express certain >things, including > . restrictions on ordering (an | does not imply that the elements >have to appear in order) > . any restriction on duplication > . the role of identifiers or restrictions on their names (e.g., "int >int" may be legal in a BNF specification but the compiler may still >complain) > > For details, see for example, pg. 172 of Aho/Sethi/Ullman: > > "Certain constraints on the input, such as the requirement that >identifiers be declared before they are used, cannot be described by a >context-free grammar." > > >If there are places where the grammar needs to be tightened up, let me >know. > >-- >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 Mon May 1 13:22:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00690 for ; Mon, 1 May 2000 13:22:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A7EA54433A; Mon, 1 May 2000 13:16:57 -0400 (EDT) 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 133F444336 for ; Mon, 1 May 2000 13:16:55 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 1 13:20:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id B541044344; Mon, 1 May 2000 13:07:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 8CB6644341 for ; Mon, 1 May 2000 13:07:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4AD9152BB; Mon, 1 May 2000 13:07:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8225952AB for ; Mon, 1 May 2000 13:07:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 1 13:05:48 EDT 2000 Received: from bounty.cisco.com ([161.44.3.204]) by dusty; Mon May 1 13:05:47 EDT 2000 Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA18642; Mon, 1 May 2000 13:05:43 -0400 (EDT) Message-ID: <390DB967.CBA8060D@cisco.com> Date: Mon, 01 May 2000 13:05:43 -0400 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: SIP IETF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Second try : Questions about REGISTER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit In section 16.1 of RFC2543bis there is an example of Registration. I have a couple of questions about this scenario. I would appreciate any responses. 1) What would be the To header of the REGISTER that T. Watson sends to the registrar at example.com. Would it be tawatson@example.com or tawatson@bell-tel.com ?? As per the description in section 4.2.6, To header domain could be different from the domain of the Request-URI in the REGISTER. 2) Let us say x@bell-tel.com (From: x@bell-tel.com) sends an INVITE to the proxy at bell-tel.com and the Request-URI is INVITE watson@bell-tel.com. As per the latest registration, the Contact is tawatson@example.com, so the proxy at bell-tel.com rewrites the Request-URI and sends it to the proxy at example.com - INVITE tawatson@example.com. Now what is the search key at the registrar - is it user@domain or simply user. If it is simply user, then domain of To header in REGISTER is meaningless. If it is user@domain, then To header of the REGISTER sent to the registrar at example.com must be tawatson@example.com. 3) What if there already exists a user tawatson at the domain example.com. Should the registrar at example.com reject the registration ?? If yes, what response code should be used ?? Thanks, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 00:52:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13256 for ; Tue, 2 May 2000 00:52:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE3D444358; Tue, 2 May 2000 00:46:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 71D7A44336 for ; Tue, 2 May 2000 00:46:45 -0400 (EDT) Received: from dynamicsoft.com (1Cust235.tnt2.freehold.nj.da.uu.net [63.17.114.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA28938; Tue, 2 May 2000 00:51:53 -0400 (EDT) Message-ID: <390E6114.8BD6D0E4@dynamicsoft.com> Date: Tue, 02 May 2000 01:01:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Henning Schulzrinne , Sip Mail List Subject: Re: [Fwd: [SIP] Sip URL and escaped characters. RFC 2543Section 2] References: <39092496.2C0ABAE6@dynamicsoft.com> <4.2.0.58.20000501093054.00cefdf0@lint.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit You definitely want to handle things like this. There are many innovative services that are enabled by placing URLs like this in web pages, Contact headers in redirects, or inside of instant messages. -Jonathan R. Rohan Mahy wrote: > > Hi, > > I just want to make sure that we can handle/describe the escaping of a > nested monster such as this: (sorrry for the wrapping at hyphens) > > href=" +14083079999@sip.cisco.com:5060;user=phone?Request-Disposition=no-fork&Accep > t-Contact=*;mobility="mobile",*;media="audio">&Request-Disposition=parallel>"> > > this would be a SIP URI inside an HTML page, that asks userA's "Butler" > (wherever he/she might be) to call (presumably userA's) cell phone. > > this particular example may be a bit contrived, but i can come up with > legitimate uses of this kind of functionality. > > thanks, > -rohan > > At 11:37 AM 4/29/00 , Henning Schulzrinne wrote: > >Maybe time to summarize and see if there's an issue left: > > > >- The host part of the URL cannot contain %, either as itself or as an > >escape mechanism: > > > >host = hostname | IPv4address > >hostname = *( domainlabel "." ) toplabel [ "." ] > >domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum > >toplabel = alpha | alpha *( alphanum | "-" ) alphanum > >alphanum = alpha | digit > > > >- For "token" elements in URLs, this is a bit tricky, since we have two > >escape mechanisms that are intersecting: > > > > (1) the normal token definition, i.e., any letter, digit, and a large > >number of symbols (-, #, $, &, %, ^, *, _, +, |, ~, ') > > > > (2) the rules for URLs, where some of these characters (&, +) are > >reserved and thus need to be escaped if there's the possibility of > >confusion with a separator. As far as I can tell, neither of them are > >syntactically relevant for SIP URLs in this context (the & is only used > >to separate 'header' items), so neither of them would need to be > >escaped. > > > >Thus, it might be better to define > > > >other-param = pname [ "=" pvalue ] > > > >pname = 1*tokenchar > >pvalue = 1*tokenchar | quoted-string > >tokenchar = alphanum | escaped | "!" | "'" | "*" | "." > > | "^" | "_" | "~" | "|" | "%" | "-" | "#" | "/" | ":" | "@" > >| "&" | "+" | "$" > > > >(since "," is not valid in token, I didn't include it. Any that I'm > >missing?) > > > >Here, escaped can only refer to the legal characters (alphanum and the > >others) to maintain "tokenness", but I can't express this in the BNF. > >However, in practice this is not a problem except for spec-writers since > >the pname and pvalue tokens have to be drawn from an enumeration, so > >that most character combinations are invalid simply because they are not > >valid parameter names. > > > >- To make matters slightly more confusing, we do have a different > >potential problem, namely the " in the quoted string. The <"> is a > >"delims" character and thus must be escaped (RFC 2396, pg. 9/10). One > >could argue that it only needs to be escaped if there's a possibility > >for confusion, e.g., on a web page or if the URL appears in a quoted > >string. However, either should be accepted by the parser. > > > > > >- In URLs, %hex hex (where allowed) is always interpreted as an escape > >mechanism. It is mechanically translated to the equivalent character, > >while maintaining its distinct identity as a non-separator (if it could > >be treated as such). Thus, > > > >foo%40bar@host.com > > > >can't just be translated into foo@bar@host.com and then be parsed, since > >the result would not be as expected. This is not fundamentally different > >from other escape mechanisms for delimiters, like \" or "". > > > >Thus, one should *first* split the URL into components and then > >translate those parts where escaping is possible (which is pretty much > >anywhere except in scheme and host). > > > >- As was pointed out, BNF specifies syntax. It cannot express certain > >things, including > > . restrictions on ordering (an | does not imply that the elements > >have to appear in order) > > . any restriction on duplication > > . the role of identifiers or restrictions on their names (e.g., "int > >int" may be legal in a BNF specification but the compiler may still > >complain) > > > > For details, see for example, pg. 172 of Aho/Sethi/Ullman: > > > > "Certain constraints on the input, such as the requirement that > >identifiers be declared before they are used, cannot be described by a > >context-free grammar." > > > > > >If there are places where the grammar needs to be tightened up, let me > >know. > > > >-- > >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 2 01:04:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13403 for ; Tue, 2 May 2000 01:04:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 362944434C; Tue, 2 May 2000 00:58:53 -0400 (EDT) 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 B62D744349 for ; Tue, 2 May 2000 00:58:50 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 01:02:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A8BD244344; Tue, 2 May 2000 00:49:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7C65044341 for ; Tue, 2 May 2000 00:49:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3DDB052BB; Tue, 2 May 2000 00:49:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5769A52AB for ; Tue, 2 May 2000 00:49:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 00:47:06 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue May 2 00:47:05 EDT 2000 Received: from dynamicsoft.com (1Cust235.tnt2.freehold.nj.da.uu.net [63.17.114.235]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA28934; Tue, 2 May 2000 00:48:17 -0400 (EDT) Message-ID: <390E603C.10ED09F5@dynamicsoft.com> Date: Tue, 02 May 2000 00:57:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: SIP IETF Subject: Re: [SIP] Second try : Questions about REGISTER References: <390DB967.CBA8060D@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > In section 16.1 of RFC2543bis there is an example of Registration. I > have > a couple of questions about this scenario. I would appreciate any > responses. > > 1) What would be the To header of the REGISTER that T. Watson sends to > the registrar at example.com. Would it be tawatson@example.com or > tawatson@bell-tel.com ?? As per the description in section 4.2.6, To > header > domain could be different from the domain of the Request-URI in the > REGISTER. Most likely tawatson@example.com. This is because if some UAC or proxy wants to send a request to tawatson@example.com, it will use DNS to find the SIP server for example.com, and forward the request there. As a result, watson will want to register tawatson@example.com with the server for which requests to example.com will be routed. The spec does not prohibit registering tawatson@bell-tel.com with example.com. However, example.com is not likely to receive requests with domains of bell-tel.com in the request URI. > > 2) Let us say x@bell-tel.com (From: x@bell-tel.com) sends an INVITE to > the > proxy at bell-tel.com and the Request-URI is INVITE watson@bell-tel.com. > As per the latest registration, the Contact is tawatson@example.com, so > the proxy at bell-tel.com rewrites the Request-URI and sends it to the > proxy at example.com - INVITE tawatson@example.com. Now what is the > search > key at the registrar - is it user@domain or simply user. If it is simply > user, > then domain of To header in REGISTER is meaningless. If it is > user@domain, > then To header of the REGISTER sent to the registrar at example.com must > be > tawatson@example.com. Thats your choice. If your proxy only handles a single domain, using user alone as a lookup key into your database is fine. If your proxy handles multiple domains, you will want to use the complete user@host. > > 3) What if there already exists a user tawatson at the domain > example.com. > Should the registrar at example.com reject the registration ?? If yes, > what response code should be used ?? No, the new Contact would be added to the existing registration. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 2 06:36:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26550 for ; Tue, 2 May 2000 06:36:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A9F84433A; Tue, 2 May 2000 06:31:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 0989E44336 for ; Tue, 2 May 2000 06:30:57 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id MAA13448 for ; Tue, 2 May 2000 12:35:06 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id MAA15219 for ; Tue, 2 May 2000 12:33:59 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id MAA00098 for ; Tue, 2 May 2000 12:34:16 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA4CB2; Tue, 2 May 2000 12:43:38 +0200 Message-ID: <390EB029.EC947C8A@italtel.it> Date: Tue, 02 May 2000 12:38:33 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: James Yu Cc: "'James Kempf'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Yu wrote: > James, > > Your question can be addressed by sigtran - SS7 transport over IP. There > are a few adaptation layers to choose including the newly proposed SUA (for > SCCP users such as IS-41). > > James Yu > Yes. You definetly don' t need SIP if you only want to tunnel legacy signalling protocols over IP: SIGTRAN does the job much better (providing for endpoint redundancy, scalability, through the concept of multiple streams within an association, encompassing a very efficient SACKs implementation that gives its best in case of retranmission of small chunks of information, just like signaling messages, and.... really much more). IMHO, you should tunnel in SIP (over SCTP, maybe) when you really add something to the base protocol, e.g by means of the SDP attributes SIP can carry, that allow for the negotiation of much richer sessions. The point is that this is actually the case, at least in many 3G cellular scenarios. A completely new (SIP-based if SIP can provide all the necessary features) approach could be also welcome in many cases. Giuseppe ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@Eng.Sun.COM] > > Sent: Friday, April 14, 2000 5:59 PM > > To: sip@lists.bell-labs.com > > Cc: James.Kempf@Eng.Sun.COM > > Subject: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol > > > > > > I'm working on a design for replacing the IS-41 North > > American cellular > > signalling protocol with IP protocols. I had a couple of > > questions about > > how the SIP INFO method, or potentially another SIP method, might > > be used. > > > > 1) In the introduction to draft-ietf-sip-info-method-03.txt, exchange > > of radio signal strength information is explicitly mentioned as > > an application of the SIP INFO method. The HandoffMeasurementRequest > > and HandoffMeasurementRequest2 messages in IS-41 are sent by > > the anchor > > Mobile Switching Center (MSC) to a potential serving MSC to > > obtain information > > about the signal strength of a Mobile Station (MS) in order > > to determine > > if the potential serving MSC is a better candidate for handling the > > mobile's call (called "hard handoff" in cellular jargon). > > They could be > > replaced with a SIP INFO method. There are three problems: > > > > a) The radio information is always solicited by the anchor MSC, > > and from the ID, the SIP INFO method seems like it is > > sent unsolicted. I suppose one could come up with two INFO > > methods, one to solicit the radio information and one to > > return it, but this seems like a hack somehow. > > > > b) In the ID, it explicitly states that the INFO method is > > only applicable when there is a call in progress. Problem is, > > there isn't a call in progress between the anchor MSC and > > the serving MSC, that's why the anchor MSC is soliciting > > the radio quality information in the first place. > > > > c) The INFO method seems like it is meant to be sent between > > SIP UAC's, while the HandoffMeasurementRequest(2) methods > > are primarily designed to be sent between network elements. > > A SIP replacement would probably be sent between the > > last hop SIP > > proxies acting as Call Agents (CAs) for the call, which replaces > > the MSC in an all IP network. > > > > 2) There are a bunch of IS-41 messages that involve transmitting > > feature or other information between the MS's Home Location > > Register (HLR) and the MS. These are initiated by either the serving > > MSC or the HLR. Examples are InformationDirective, which is used > > by the HLR to provide notifications to an idle MS, and FeatureRequest, > > which sends particular features to a potentially idle MS (features > > being things like messages or playing particular tones). Again, these > > seem like candidates to replace with the SIP INFO message, but > > the potential lack of any call in progress would prohibit that. > > > > The alternative I could see would be establishing a session in order > > to then send the information via the INFO method, but that seems like > > overkill. And in the case of HandoffMeasurementRequest(2), the > > message isn't intended for a SIP UAC anyway. > > > > Maybe SIP is the wrong protocol to consider, since it is dedicated > > to setting up and maintaining sessions, and not to exchanging > > information > > between network elements or between network elements and terminals? > > > > Can anybody provide some guidance? > > > > jak > > > > > > > > _______________________________________________ > > 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 -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 08:52:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29534 for ; Tue, 2 May 2000 08:52:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C91044344; Tue, 2 May 2000 08:47:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 63E0C44336 for ; Tue, 2 May 2000 08:46:58 -0400 (EDT) Received: by dnspri.npac.com; id HAA08299; Tue, 2 May 2000 07:52:12 -0500 (CDT) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma008162; Tue, 2 May 00 07:51:25 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 07:51:13 -0500 Message-ID: From: James Yu To: "'Giuseppe Ricagni'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol Date: Tue, 2 May 2000 07:50:34 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Cellular intersystem operations can be separated into two types: transaction based (e.g., for roaming support and handoff measurement) and call- or service-related (for call setup during handoff and for intelligent network call/service control). Call-related operations certainly can be supported by SIP. Service control related operations probably are best supported by MGCP/megaco if WIN/CAP are not to be used. If WIN/CAP are used for call/service control, sigtran would be the choice to carry the protocol. Transaction based operations probably can just use sigtran to transport the messages. You can always add new parameters to IS-41 or GSM MAP to carry SDP information. My earlier comment was about the handoff measurement part where no call set up is needed. But I think you are looking at SIP or something else to totally replace IS-41 (so as not to enhance IS-41 to support 3G)- so please continue the search/investigation. James > -----Original Message----- > From: Giuseppe Ricagni [mailto:giuseppe.ricagni@italtel.it] > Sent: Tuesday, May 02, 2000 6:39 AM > To: James Yu > Cc: 'James Kempf'; sip@lists.bell-labs.com > Subject: Re: [SIP] SIP Info Method and IS-41 Cellular Signalling > Protocol > > > James Yu wrote: > > > James, > > > > Your question can be addressed by sigtran - SS7 transport > over IP. There > > are a few adaptation layers to choose including the newly > proposed SUA (for > > SCCP users such as IS-41). > > > > James Yu > > > > Yes. > > You definetly don' t need SIP if you only want to tunnel legacy > signalling > protocols over IP: SIGTRAN does the job much better (providing for > endpoint > redundancy, scalability, through the concept of multiple > streams within > an > association, encompassing a very efficient SACKs implementation that > gives its > best in case of retranmission of small chunks of information, > just like > signaling messages, and.... really much more). > > IMHO, you should tunnel in SIP (over SCTP, maybe) when you really add > something > to the base protocol, e.g by means of the SDP attributes SIP > can carry, > that > allow for the negotiation of much richer sessions. > > The point is that this is actually the case, at least in many 3G > cellular > scenarios. > > A completely new (SIP-based if SIP can provide all the necessary > features) > approach could be also welcome in many cases. > > Giuseppe > > > > ---------------------------------------------------------- > Giuseppe RICAGNI > System Architecture and Product Planning > Broadband Networks > Italtel > via Reiss Romoli - C10 > 20019 Castelletto di Settimo Milanese (MILANO) > ITALY > > mailto:giuseppe.ricagni@italtel.it > ---------------------------------------------------------- > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 13:34:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05945 for ; Tue, 2 May 2000 13:34:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD92C4433B; Tue, 2 May 2000 13:28:48 -0400 (EDT) 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 1759844336 for ; Tue, 2 May 2000 13:28:46 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue May 2 13:32:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1FD7E44344; Tue, 2 May 2000 13:19:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E972544341 for ; Tue, 2 May 2000 13:19:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B29B452BB; Tue, 2 May 2000 13:19:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BEA4752AB for ; Tue, 2 May 2000 13:19:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 13:18:30 EDT 2000 Received: from bounty.cisco.com ([161.44.3.204]) by dusty; Tue May 2 13:18:29 EDT 2000 Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA19795; Tue, 2 May 2000 13:18:24 -0400 (EDT) Message-ID: <390F0DE0.EED96548@cisco.com> Date: Tue, 02 May 2000 13:18:24 -0400 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: SIP IETF Subject: Re: [SIP] Second try : Questions about REGISTER References: <390DB967.CBA8060D@cisco.com> <390E603C.10ED09F5@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, Appreciate your responses. See embedded . Shail Jonathan Rosenberg wrote: > > Shail Bhatnagar wrote: > > > > In section 16.1 of RFC2543bis there is an example of Registration. I > > have > > a couple of questions about this scenario. I would appreciate any > > responses. > > > > 1) What would be the To header of the REGISTER that T. Watson sends to > > the registrar at example.com. Would it be tawatson@example.com or > > tawatson@bell-tel.com ?? As per the description in section 4.2.6, To > > header > > domain could be different from the domain of the Request-URI in the > > REGISTER. > > Most likely tawatson@example.com. This is because if some UAC or proxy > wants to send a request to tawatson@example.com, it will use DNS to find > the SIP server for example.com, and forward the request there. As a > result, watson will want to register tawatson@example.com with the > server for which requests to example.com will be routed. The spec does > not prohibit registering tawatson@bell-tel.com with example.com. > However, example.com is not likely to receive requests with domains of > bell-tel.com in the request URI. This is exactly my point of confusion. The text in 4.2.6 is actually raising more questions than answering. I cannot think of a case when a mismatch in the domain of To header and Request-URI would be useful. If the proxy services more than 2 domains, the domain in To header and Request-URI would still be same or may be I am missing something. > > > > > 2) Let us say x@bell-tel.com (From: x@bell-tel.com) sends an INVITE to > > the > > proxy at bell-tel.com and the Request-URI is INVITE watson@bell-tel.com. > > As per the latest registration, the Contact is tawatson@example.com, so > > the proxy at bell-tel.com rewrites the Request-URI and sends it to the > > proxy at example.com - INVITE tawatson@example.com. Now what is the > > search > > key at the registrar - is it user@domain or simply user. If it is simply > > user, > > then domain of To header in REGISTER is meaningless. If it is > > user@domain, > > then To header of the REGISTER sent to the registrar at example.com must > > be > > tawatson@example.com. > > Thats your choice. If your proxy only handles a single domain, using > user alone as a lookup key into your database is fine. If your proxy > handles multiple domains, you will want to use the complete user@host. > > > > > 3) What if there already exists a user tawatson at the domain > > example.com. > > Should the registrar at example.com reject the registration ?? If yes, > > what response code should be used ?? > > No, the new Contact would be added to the existing registration. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 May 2 17:18:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09022 for ; Tue, 2 May 2000 17:18:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 782F34433B; Tue, 2 May 2000 17:12:50 -0400 (EDT) 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 1E9FA44336 for ; Tue, 2 May 2000 17:12:48 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 17:16:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F3AAB44344; Tue, 2 May 2000 17:03:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C108744341 for ; Tue, 2 May 2000 17:03:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5EA1952BB; Tue, 2 May 2000 17:03:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7ADEE52AB for ; Tue, 2 May 2000 17:03:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 17:01:11 EDT 2000 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by dusty; Tue May 2 17:01:09 EDT 2000 Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 May 2000 11:48:41 -0700 (Pacific Daylight Time) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [SIP] Second try : Questions about REGISTER Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB467.0741FEE0" X-MimeOLE: Produced By Microsoft Exchange V6.0.4350.0 Date: Tue, 2 May 2000 11:48:38 -0700 Message-ID: Thread-Topic: [SIP] Second try : Questions about REGISTER Thread-Index: Ab+z8/NEr4KGPEYiRJaUKeKO2ilE2AAcwIdA From: "Alexandru Gavrilescu" To: "Jonathan Rosenberg" , "Shail Bhatnagar" Cc: "SIP IETF" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------_=_NextPart_001_01BFB467.0741FEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a question regarding Jonathan's answer to the Shail's third question. Do we assume that tawatson has an account created for himself at example.com or he is just a visitor at example.com? I assume the first. What would be the behaviour is tawatson@bell-tell.com would be just a visitor at example.com? =20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, May 01, 2000 9:58 PM To: Shail Bhatnagar Cc: SIP IETF Subject: Re: [SIP] Second try : Questions about REGISTER Shail Bhatnagar wrote: >=20 > In section 16.1 of RFC2543bis there is an example of Registration. I > have > a couple of questions about this scenario. I would appreciate any > responses. >=20 > 1) What would be the To header of the REGISTER that T. Watson sends to > the registrar at example.com. Would it be tawatson@example.com or > tawatson@bell-tel.com ?? As per the description in section 4.2.6, To > header > domain could be different from the domain of the Request-URI in the > REGISTER. Most likely tawatson@example.com. This is because if some UAC or proxy wants to send a request to tawatson@example.com, it will use DNS to find the SIP server for example.com, and forward the request there. As a result, watson will want to register tawatson@example.com with the server for which requests to example.com will be routed. The spec does not prohibit registering tawatson@bell-tel.com with example.com. However, example.com is not likely to receive requests with domains of bell-tel.com in the request URI. >=20 > 2) Let us say x@bell-tel.com (From: x@bell-tel.com) sends an INVITE to > the > proxy at bell-tel.com and the Request-URI is INVITE watson@bell-tel.com. > As per the latest registration, the Contact is tawatson@example.com, so > the proxy at bell-tel.com rewrites the Request-URI and sends it to the > proxy at example.com - INVITE tawatson@example.com. Now what is the > search > key at the registrar - is it user@domain or simply user. If it is simply > user, > then domain of To header in REGISTER is meaningless. If it is > user@domain, > then To header of the REGISTER sent to the registrar at example.com must > be > tawatson@example.com. Thats your choice. If your proxy only handles a single domain, using user alone as a lookup key into your database is fine. If your proxy handles multiple domains, you will want to use the complete user@host. >=20 > 3) What if there already exists a user tawatson at the domain > example.com. > Should the registrar at example.com reject the registration ?? If yes, > what response code should be used ?? No, the new Contact would be added to the existing registration.=20 -Jonathan R. --=20 Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFB467.0741FEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Second try : Questions about REGISTER

I have a question regarding Jonathan's answer to the = Shail's third question.
Do we assume that tawatson has an account created for = himself at example.com or he is just a visitor at example.com?
I assume the first.
What would be the behaviour is tawatson@bell-tell.com = would be just a visitor at example.com?

 
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, May 01, 2000 9:58 PM
To: Shail Bhatnagar
Cc: SIP IETF
Subject: Re: [SIP] Second try : Questions about = REGISTER




Shail Bhatnagar wrote:
>
> In section 16.1 of RFC2543bis there is an = example of Registration. I
> have
> a couple of questions about this scenario. I = would appreciate any
> responses.
>
> 1) What would be the To header of the REGISTER = that T. Watson sends to
> the registrar at example.com. Would it be = tawatson@example.com or
> tawatson@bell-tel.com ?? As per the description = in section 4.2.6, To
> header
> domain could be different from the domain of the = Request-URI in the
> REGISTER.

Most likely tawatson@example.com. This is because if = some UAC or proxy
wants to send a request to tawatson@example.com, it = will use DNS to find
the SIP server for example.com, and forward the = request there. As a
result, watson will want to register = tawatson@example.com with the
server for which requests to example.com will be = routed. The spec does
not prohibit registering tawatson@bell-tel.com with = example.com.
However, example.com is not likely to receive = requests with domains of
bell-tel.com in the request URI.

>
> 2) Let us say x@bell-tel.com (From: = x@bell-tel.com) sends an INVITE to
> the
> proxy at bell-tel.com and the Request-URI is = INVITE watson@bell-tel.com.
> As per the latest registration, the Contact is = tawatson@example.com, so
> the proxy at bell-tel.com rewrites the = Request-URI and sends it to the
> proxy at example.com - INVITE = tawatson@example.com. Now what is the
> search
> key at the registrar - is it user@domain or = simply user. If it is simply
> user,
> then domain of To header in REGISTER is = meaningless. If it is
> user@domain,
> then To header of the REGISTER sent to the = registrar at example.com must
> be
> tawatson@example.com.

Thats your choice. If your proxy only handles a single = domain, using
user alone as a lookup key into your database is = fine. If your proxy
handles multiple domains, you will want to use the = complete user@host.


>
> 3) What if there already exists a user tawatson = at the domain
> example.com.
> Should the registrar at example.com reject the = registration ?? If yes,
> what response code should be used ??

No, the new Contact would be added to the existing = registration.

-Jonathan R.

--
Jonathan D. = Rosenberg          &nbs= p;            72 = Eagle Rock Ave.
Chief = Scientist          &nbs= p;            = ;      First Floor
dynamicsoft         = ;            =             East = Hanover, NJ 07936
jdrosen@dynamicsoft.com       = ;            =   FAX:   (732) 741-4778
http://www.cs.columbia.edu/~= jdrosen         PHONE: (732) = 741-7244
http://www.dynamicsoft.com=


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

------_=_NextPart_001_01BFB467.0741FEE0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 18:02:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09557 for ; Tue, 2 May 2000 18:02:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8A3544340; Tue, 2 May 2000 17:56:46 -0400 (EDT) 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 9539C44336 for ; Tue, 2 May 2000 17:56:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 18:00:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 04B1044344; Tue, 2 May 2000 17:47:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C5C6844341 for ; Tue, 2 May 2000 17:47:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 86C0952BB; Tue, 2 May 2000 17:47:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 827CE52B6 for ; Tue, 2 May 2000 17:47:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 17:46:52 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue May 2 17:46:51 EDT 2000 Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA01221; Tue, 2 May 2000 17:48:05 -0400 (EDT) Message-ID: <390F4F3F.62D59146@dynamicsoft.com> Date: Tue, 02 May 2000 17:57:19 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: SIP IETF Subject: Re: [SIP] Second try : Questions about REGISTER References: <390DB967.CBA8060D@cisco.com> <390E603C.10ED09F5@dynamicsoft.com> <390F0DE0.EED96548@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > > > 1) What would be the To header of the REGISTER that T. Watson sends to > > > the registrar at example.com. Would it be tawatson@example.com or > > > tawatson@bell-tel.com ?? As per the description in section 4.2.6, To > > > header > > > domain could be different from the domain of the Request-URI in the > > > REGISTER. > > > > Most likely tawatson@example.com. This is because if some UAC or proxy > > wants to send a request to tawatson@example.com, it will use DNS to find > > the SIP server for example.com, and forward the request there. As a > > result, watson will want to register tawatson@example.com with the > > server for which requests to example.com will be routed. The spec does > > not prohibit registering tawatson@bell-tel.com with example.com. > > However, example.com is not likely to receive requests with domains of > > bell-tel.com in the request URI. > > This is exactly my point of confusion. The text in 4.2.6 is actually > raising > more questions than answering. I cannot think of a case when a mismatch > in > the domain of To header and Request-URI would be useful. If the proxy > services > more than 2 domains, the domain in To header and Request-URI would still > be > same or may be I am missing something. I think this text just requires additional clarification. There are cases where this can work (namely, when there is specialized routing logic at a server), but we need to give an example and the limitations. For 99% of the applications, the domain in the request URI and To field will be identical. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 2 18:20:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09747 for ; Tue, 2 May 2000 18:20:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6419844340; Tue, 2 May 2000 18:14:47 -0400 (EDT) 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 DCC5A44336 for ; Tue, 2 May 2000 18:14:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue May 2 18:18:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0896344344; Tue, 2 May 2000 18:05:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C75E944341 for ; Tue, 2 May 2000 18:05:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 76DE752BB; Tue, 2 May 2000 18:05:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B0D5E52B6 for ; Tue, 2 May 2000 18:05:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 18:03:20 EDT 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 2 18:03:19 EDT 2000 Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA09897 for ; Tue, 2 May 2000 18:03:15 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id SAA34631; Tue, 2 May 2000 18:03:14 -0400 (EDT) (envelope-from lennox) Date: Tue, 2 May 2000 18:03:14 -0400 (EDT) Message-Id: <200005022203.SAA34631@conrail.cs.columbia.edu> From: Jonathan Lennox To: sip@lists.research.bell-labs.com Subject: [SIP] Problem with the syntax of URI extension parameters Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com RFC 2543 (and the current bis draft) defines the BNF for SIP URLs' extension parameters as follows: other-param = ( token | ( token "=" ( token | quoted-string ))) The problem with this is that RFC 2396 (URI Generic Syntax) specifically excludes quote marks from URIs, since they're a common URI delimeter in text documents and protocol fields. What's more, both the "token" and "quoted-string" syntax elements come from a very different part of the SIP BNF; and no other URI syntax, as far as I know, uses anything like them. I think it'd be much more in the spirit of the generic URI syntax to have other-param be defined like this: other-param = pname | pname "=" pvalue pname = 1*paramchar pvalue = 1*paramchar paramchar = param-reserved | unreserved | escaped param-reserved = "/" | "?" | ":" | "@" | "&" | "+" | "$" | "," That is, special characters get %-escaped rather than quoted. "param-reserved" above is the same as the general "reserved" with ";" and "=", the parameter delimiters, omitted. This would, however, be an incompatible change to the SIP spec. What would people (especially the spec authors) think about this? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 18:42:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09978 for ; Tue, 2 May 2000 18:42:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E48BE44343; Tue, 2 May 2000 18:36:48 -0400 (EDT) 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 57F5744340 for ; Tue, 2 May 2000 18:36:46 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 18:40:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F075644344; Tue, 2 May 2000 18:27:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BD53244341 for ; Tue, 2 May 2000 18:27:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 78E8B52BB; Tue, 2 May 2000 18:27:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 7A14C52B6 for ; Tue, 2 May 2000 18:27:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue May 2 18:25:44 EDT 2000 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Tue May 2 18:25:44 EDT 2000 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FTY00L36EAK1R@firewall.mcit.com> for sip@lists.research.bell-labs.com; Tue, 2 May 2000 22:25:32 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FTY00J01EAF0M@dgismtp02.wcomnet.com>; Tue, 02 May 2000 22:25:32 +0000 (GMT) Received: from omzmta03.mcit.com ([166.37.214.9]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FTY00HLHEACF2@dgismtp02.wcomnet.com>; Tue, 02 May 2000 22:25:24 +0000 (GMT) Received: from dwillispc8 ([166.35.152.155]) by omzmta03.mcit.com (InterMail v03.02.07 118-124-101) with SMTP id <20000502222522.USCD20964@dwillispc8>; Tue, 02 May 2000 22:25:22 +0000 Date: Tue, 02 May 2000 17:24:49 -0500 From: Dean Willis Subject: RE: [SIP] Second try : Questions about REGISTER In-reply-to: <390F4F3F.62D59146@dynamicsoft.com> To: Jonathan Rosenberg , Shail Bhatnagar Cc: SIP IETF Message-id: <001b01bfb485$3a4650c0$9b9823a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > This is exactly my point of confusion. The text in 4.2.6 is actually > > raising > > more questions than answering. I cannot think of a case when a mismatch > > in > > the domain of To header and Request-URI would be useful. If the proxy > > services > > more than 2 domains, the domain in To header and Request-URI would still > > be > > same or may be I am missing something. > > I think this text just requires additional clarification. There are > cases where this can work (namely, when there is specialized routing > logic at a server), but we need to give an example and the limitations. > For 99% of the applications, the domain in the request URI and To field > will be identical. True, it is unlikley that an original UAC will generate a request with variant fields. However, I might suggest that a mismatch between request-URI and To: field will inevitably occur if a previous proxy in the path has applied routing logic that results in a new request-URI being applied. For example, let's say my work proxy forwards to my home proxy: So an original INVITE might contain: INVITE sip:dean.willis@wcom.com SIP/2.0 To: Dean Willis and after leaving the wcom.com proxy (which, based on time-of-day, forwards to my house) INVITE sip:dwillis@sip.softarmor.com SIP/2.0 TO: Dean Willis So the destination UAS (my trusty sip-phone) would see an INVITE in which the request-URI does not match the To: field. -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 19:10:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10189 for ; Tue, 2 May 2000 19:10:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E52844340; Tue, 2 May 2000 19:04:47 -0400 (EDT) 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 D5CEF44336 for ; Tue, 2 May 2000 19:04:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 19:08:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id B6FB544344; Tue, 2 May 2000 18:55:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7FA1844341 for ; Tue, 2 May 2000 18:55:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4986B52BB; Tue, 2 May 2000 18:55:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 733B952AB for ; Tue, 2 May 2000 18:55:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 18:53:19 EDT 2000 Received: from bounty.cisco.com ([161.44.3.204]) by dusty; Tue May 2 18:53:18 EDT 2000 Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id SAA09243; Tue, 2 May 2000 18:53:12 -0400 (EDT) Message-ID: <390F5C58.AFEE47C1@cisco.com> Date: Tue, 02 May 2000 18:53:12 -0400 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: Jonathan Rosenberg , SIP IETF Subject: Re: [SIP] Second try : Questions about REGISTER References: <001b01bfb485$3a4650c0$9b9823a6@mcit.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I was referring to REGISTER request, not to other requests. Dean Willis wrote: > > > > This is exactly my point of confusion. The text in 4.2.6 is actually > > > raising > > > more questions than answering. I cannot think of a case when a mismatch > > > in > > > the domain of To header and Request-URI would be useful. If the proxy > > > services > > > more than 2 domains, the domain in To header and Request-URI would still > > > be > > > same or may be I am missing something. > > > > I think this text just requires additional clarification. There are > > cases where this can work (namely, when there is specialized routing > > logic at a server), but we need to give an example and the limitations. > > For 99% of the applications, the domain in the request URI and To field > > will be identical. > > True, it is unlikley that an original UAC will generate a request with > variant fields. > > However, I might suggest that a mismatch between request-URI and To: field > will inevitably occur if a previous proxy in the path has applied routing > logic that results in a new request-URI being applied. > > For example, let's say my work proxy forwards to my home proxy: > > So an original INVITE might contain: > > INVITE sip:dean.willis@wcom.com SIP/2.0 > To: Dean Willis > > and after leaving the wcom.com proxy (which, based on time-of-day, forwards > to my house) > > INVITE sip:dwillis@sip.softarmor.com SIP/2.0 > TO: Dean Willis > > So the destination UAS (my trusty sip-phone) would see an INVITE in which > the request-URI does not match the To: field. > > -- > Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 19:40:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10421 for ; Tue, 2 May 2000 19:40:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8958A4433B; Tue, 2 May 2000 19:34:46 -0400 (EDT) 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 0F75744336 for ; Tue, 2 May 2000 19:34:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 19:38:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0A99244344; Tue, 2 May 2000 19:25:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id CF7DC44341 for ; Tue, 2 May 2000 19:25:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8F55852BB; Tue, 2 May 2000 19:25:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AB84652AB for ; Tue, 2 May 2000 19:25:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 19:23:12 EDT 2000 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by dusty; Tue May 2 19:23:11 EDT 2000 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FTY00KNNGYMLR@firewall.mcit.com> for sip@lists.research.bell-labs.com; Tue, 2 May 2000 23:23:10 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FTY00001GYJLT@dgismtp02.wcomnet.com>; Tue, 02 May 2000 23:23:10 +0000 (GMT) Received: from omzmta03.mcit.com ([166.37.214.9]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FTY00LNJGYEP0@dgismtp02.wcomnet.com>; Tue, 02 May 2000 23:23:02 +0000 (GMT) Received: from dwillispc8 ([166.35.152.155]) by omzmta03.mcit.com (InterMail v03.02.07 118-124-101) with SMTP id <20000502232302.VCDI20964@dwillispc8>; Tue, 02 May 2000 23:23:02 +0000 Date: Tue, 02 May 2000 18:22:29 -0500 From: Dean Willis Subject: RE: [SIP] Second try : Questions about REGISTER In-reply-to: <390F5C58.AFEE47C1@cisco.com> To: shbhatna@cisco.com Cc: Jonathan Rosenberg , SIP IETF Message-id: <002001bfb48d$48b568a0$9b9823a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Pardon me for not carrying the thought out. I committed premature sending again. Need keyboard viagra or something. Ok, we've seen from my previous example how an INVITE with a To: that does not match the request-URI can show up at my home proxy. What does my home proxy DO with that INVITE? It could follow the usual wisdom, and simply process the INVITE according to the rules applicable to the entity specified by the request-URI. What if I wanted a little more power in my call handling? For example, I might want my home proxy to divert calls that are To: dwillis@sip.softarmor.com to be diverted to my cell phone, and calls that are To: dean.willis@wcom.com (calls forwarded from work) to ring my desk phone, then be diverted to my unified messaging box if there is no answer. This implies logic processing in the home proxy based on the value of the To: header. How do I provision this logic? One possibility would be to put it in the proxy's config file as a script or action table. What if I wanted to use dynamic registration, perhaps with a CPL upload, to change proxy behavior? How would I specify that one register affects a different logical target or "To:" than another? Two possibilities: 1) There is only one registration, and the singular uploaded CPL includes To: differentiation logic. 2) I use a register message which indicates second logical destination in the To: field, and have some other way of indicating a request-chaining logic. As Jonathan says, 99%+ of all registers will have a request-URI that matches a To:. I think, however, there are services that have not been completely defined which would take advantage of REGISTER messages which have different request-URI and To: fields. Personally, I wonder why we didn't just go ahead and include the user part in the request-URI. This would allow my request-chaining REGISTER to be fairly explicitly stated and solve lots of messiness. -- Dean > -----Original Message----- > From: shbhatna@cisco.com [mailto:shbhatna@cisco.com] > Sent: Tuesday, May 02, 2000 5:53 PM > To: Dean Willis > Cc: Jonathan Rosenberg; SIP IETF > Subject: Re: [SIP] Second try : Questions about REGISTER > > > I was referring to REGISTER request, not to other requests. > > > Dean Willis wrote: > > > > > > This is exactly my point of confusion. The text in 4.2.6 is actually > > > > raising > > > > more questions than answering. I cannot think of a case > when a mismatch > > > > in > > > > the domain of To header and Request-URI would be useful. If > the proxy > > > > services > > > > more than 2 domains, the domain in To header and > Request-URI would still > > > > be > > > > same or may be I am missing something. > > > > > > I think this text just requires additional clarification. There are > > > cases where this can work (namely, when there is specialized routing > > > logic at a server), but we need to give an example and the > limitations. > > > For 99% of the applications, the domain in the request URI > and To field > > > will be identical. > > > > True, it is unlikley that an original UAC will generate a request with > > variant fields. > > > > However, I might suggest that a mismatch between request-URI > and To: field > > will inevitably occur if a previous proxy in the path has > applied routing > > logic that results in a new request-URI being applied. > > > > For example, let's say my work proxy forwards to my home proxy: > > > > So an original INVITE might contain: > > > > INVITE sip:dean.willis@wcom.com SIP/2.0 > > To: Dean Willis > > > > and after leaving the wcom.com proxy (which, based on > time-of-day, forwards > > to my house) > > > > INVITE sip:dwillis@sip.softarmor.com SIP/2.0 > > TO: Dean Willis > > > > So the destination UAS (my trusty sip-phone) would see an > INVITE in which > > the request-URI does not match the To: field. > > > > -- > > Dean > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 20:14:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10761 for ; Tue, 2 May 2000 20:14:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A00B44433B; Tue, 2 May 2000 20:08:45 -0400 (EDT) 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 5F12F44336 for ; Tue, 2 May 2000 20:08:43 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 20:12:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 95D8644344; Tue, 2 May 2000 19:59:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 606A644341 for ; Tue, 2 May 2000 19:59:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2E5E952BB; Tue, 2 May 2000 19:59:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 65B8252B6 for ; Tue, 2 May 2000 19:59:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 19:58:14 EDT 2000 Received: from imr1.ericy.com ([208.237.135.240]) by dusty; Tue May 2 19:58:13 EDT 2000 Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id SAA26279; Tue, 2 May 2000 18:58:11 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id SAA02904; Tue, 2 May 2000 18:58:02 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA20716; Tue, 2 May 2000 18:58:11 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id SAA17217; Tue, 2 May 2000 18:58:10 -0500 (CDT) Date: Tue, 2 May 2000 18:58:10 -0500 (CDT) Message-Id: <200005022358.SAA17217@b04a45.exu.ericsson.se> To: jdrosen@dynamicsoft.com, shbhatna@cisco.com Subject: Re: [SIP] Second try : Questions about REGISTER Cc: sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > This is exactly my point of confusion. The text in 4.2.6 is actually > raising > more questions than answering. I cannot think of a case when a mismatch > in > the domain of To header and Request-URI would be useful. If the proxy > services > more than 2 domains, the domain in To header and Request-URI would still > be > same or may be I am missing something. > Virtual hosting. A single SIP proxy accepts (REGISTER) requests for multiple domains. Depending on the domain, the proxy forwards the REGISTER request to a particular provisioned registrar, in the process re-writing the domain of the request URI according to that registrar's needs/whims. This could even involve forking of the REGISTER request. The To: remains (of course) unchanged. Or maybe load balancing. A single domain is split into logical sub-domains based on the a combination of the user/To/From/whatever by a front-end proxy. The request-URI is rewritten to reflect the particular sub-domain of the registrar to which the REGISTER request ultimately gets forwarded. The To: remains (of course) unchanged. Or as indicated on page 28 under the Request-URI description, the registrar acting as a VLR accepts registrations for domains other than the domain given in the Request-URI. The To: header determines the registration that is affected. The request-URI determines the domain of the registrar. These are logically separate concepts and there is no good reason to mandate that the domain in the To: is the same as the domain in the Request-URI Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 20:16:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10784 for ; Tue, 2 May 2000 20:16:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB06B44358; Tue, 2 May 2000 20:10:47 -0400 (EDT) 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 127CC44351 for ; Tue, 2 May 2000 20:10:43 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue May 2 20:14:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1A95644345; Tue, 2 May 2000 20:01:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id DBBEA44341 for ; Tue, 2 May 2000 20:01:07 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9EC7C52BB; Tue, 2 May 2000 20:01:06 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id BD25B52B6 for ; Tue, 2 May 2000 20:01:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue May 2 20:00:50 EDT 2000 Received: from imr1.ericy.com ([208.237.135.240]) by dusty; Tue May 2 20:00:49 EDT 2000 Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id TAA27174; Tue, 2 May 2000 19:00:47 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id TAA23886; Tue, 2 May 2000 19:00:47 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA20834; Tue, 2 May 2000 19:00:47 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id TAA17220; Tue, 2 May 2000 19:00:46 -0500 (CDT) Date: Tue, 2 May 2000 19:00:46 -0500 (CDT) Message-Id: <200005030000.TAA17220@b04a45.exu.ericsson.se> To: dean.willis@wcom.com Subject: RE: [SIP] Second try : Questions about REGISTER Cc: sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Personally, I wonder why we didn't just go ahead and include the user part > in the request-URI. This would allow my request-chaining REGISTER to be > fairly explicitly stated and solve lots of messiness. > > -- > Dean > I second that :) I've never understood the rationale behind excluding the user part in the Request-URI of a REGISTER request. -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 20:26:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10848 for ; Tue, 2 May 2000 20:26:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C7E644352; Tue, 2 May 2000 20:20:47 -0400 (EDT) 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 99CB244351 for ; Tue, 2 May 2000 20:20:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 20:25:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3F35144346; Tue, 2 May 2000 20:11:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1895644341 for ; Tue, 2 May 2000 20:11:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D89F752BB; Tue, 2 May 2000 20:11:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 08D5852B6 for ; Tue, 2 May 2000 20:11:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue May 2 20:10:09 EDT 2000 Received: from imr1.ericy.com ([208.237.135.240]) by dusty; Tue May 2 20:10:09 EDT 2000 Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id TAA29718; Tue, 2 May 2000 19:10:05 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id TAA05307; Tue, 2 May 2000 19:09:57 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA21128; Tue, 2 May 2000 19:10:05 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id TAA17230; Tue, 2 May 2000 19:10:05 -0500 (CDT) Date: Tue, 2 May 2000 19:10:05 -0500 (CDT) Message-Id: <200005030010.TAA17230@b04a45.exu.ericsson.se> To: sip@lists.research.bell-labs.com, lennox@cs.columbia.edu Subject: Re: [SIP] Problem with the syntax of URI extension parameters X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > RFC 2543 (and the current bis draft) defines the BNF for SIP URLs' extension > parameters as follows: > > other-param = ( token | ( token "=" ( token | quoted-string ))) > > The problem with this is that RFC 2396 (URI Generic Syntax) specifically > excludes quote marks from URIs, since they're a common URI delimeter in text > documents and protocol fields. What's more, both the "token" and > "quoted-string" syntax elements come from a very different part of the SIP > BNF; and no other URI syntax, as far as I know, uses anything like them. > > I think it'd be much more in the spirit of the generic URI syntax to have > other-param be defined like this: > > other-param = pname | pname "=" pvalue > pname = 1*paramchar > pvalue = 1*paramchar > paramchar = param-reserved | unreserved | escaped > param-reserved = "/" | "?" | ":" | "@" | "&" | "+" | "$" | "," > > That is, special characters get %-escaped rather than quoted. > "param-reserved" above is the same as the general "reserved" with ";" and > "=", the parameter delimiters, omitted. > > This would, however, be an incompatible change to the SIP spec. What would > people (especially the spec authors) think about this? > > -- > Jonathan Lennox > lennox@cs.columbia.edu > Sounds reasonable. I doubt that there are many implementations that actually accept a quoted-string as part of a SIP URL parameter value. And as you mention, in general the URI syntax doesn't allow quotes and in practice I've never seem them used. -- Sean Olson > > _______________________________________________ > 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 May 2 20:40:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10972 for ; Tue, 2 May 2000 20:40:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1188944350; Tue, 2 May 2000 20:34:46 -0400 (EDT) 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 9085F4434F for ; Tue, 2 May 2000 20:34:43 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 20:38:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7E84A44344; Tue, 2 May 2000 20:25:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 4BF3244341 for ; Tue, 2 May 2000 20:25:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1CD6152BB; Tue, 2 May 2000 20:25:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 4698A52B6 for ; Tue, 2 May 2000 20:25:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue May 2 20:23:06 EDT 2000 Received: from mw.3com.com ([149.112.20.3]) by dusty; Tue May 2 20:23:05 EDT 2000 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id TAA22575; Tue, 2 May 2000 19:23:04 -0500 (CDT) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 862568D4.00025011 ; Tue, 2 May 2000 19:25:15 -0500 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Natarajan Kalpathy" To: sip@lists.research.bell-labs.com Message-ID: <862568D4.00024F2D.00@mwgate02.mw.3com.com> Date: Tue, 2 May 2000 19:25:36 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Content Lenght in responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Why is the Content Length field not mandatory in cases of SIP responses ??. Wont it simplify the message processing in case of TCP. The current rfc2543bis draft says "If a response does not contain a Content-Length, the client assumes that it encompasses the remainder of the UDP packet or the data until the TCP connection is closed, as applicable. " Please clarify .... Natarajan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 22:24:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12557 for ; Tue, 2 May 2000 22:24:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 686054433B; Tue, 2 May 2000 22:18:45 -0400 (EDT) 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 19F3344336 for ; Tue, 2 May 2000 22:18:43 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 22:22:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7023544344; Tue, 2 May 2000 22:09:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 497A244341 for ; Tue, 2 May 2000 22:09:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 11E2F52BB; Tue, 2 May 2000 22:09:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 467A452B6 for ; Tue, 2 May 2000 22:09:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 22:07:36 EDT 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 2 22:07:36 EDT 2000 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 WAA24708; Tue, 2 May 2000 22:07:34 -0400 (EDT) Message-ID: <390F89E6.1B1995B@cs.columbia.edu> Date: Tue, 02 May 2000 22:07:34 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.research.bell-labs.com, lennox@ober.cs.columbia.edu Subject: Re: [SIP] Problem with the syntax of URI extension parameters References: <200005030010.TAA17230@b04a45.exu.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sean Olson wrote: > > > I think it'd be much more in the spirit of the generic URI syntax to have > > other-param be defined like this: > > > > other-param = pname | pname "=" pvalue > > pname = 1*paramchar > > pvalue = 1*paramchar > > paramchar = param-reserved | unreserved | escaped > > param-reserved = "/" | "?" | ":" | "@" | "&" | "+" | "$" | "," > > > > That is, special characters get %-escaped rather than quoted. > > "param-reserved" above is the same as the general "reserved" with ";" and > > "=", the parameter delimiters, omitted. > > > > This would, however, be an incompatible change to the SIP spec. What would > > people (especially the spec authors) think about this? > > > > -- > > Jonathan Lennox > > lennox@cs.columbia.edu > > > > Sounds reasonable. I doubt that there are many implementations that actually accept a > quoted-string as part of a SIP URL parameter value. And as you mention, in general > the URI syntax doesn't allow quotes and in practice I've never seem them used. Same here. Escaping the " kind of works, but is very unclean, since you are now escaping syntactically relevant delimiters. -- 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 May 2 22:32:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13260 for ; Tue, 2 May 2000 22:32:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AE93C44351; Tue, 2 May 2000 22:26:45 -0400 (EDT) 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 47D5844350 for ; Tue, 2 May 2000 22:26:43 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 22:30:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id ECE4544345; Tue, 2 May 2000 22:17:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C692644341 for ; Tue, 2 May 2000 22:17:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9041652BB; Tue, 2 May 2000 22:17:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C78D152B6 for ; Tue, 2 May 2000 22:17:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 22:15:45 EDT 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 2 22:15:44 EDT 2000 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 WAA25147; Tue, 2 May 2000 22:15:42 -0400 (EDT) Message-ID: <390F8BCE.932883E5@cs.columbia.edu> Date: Tue, 02 May 2000 22:15:42 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: dean.willis@wcom.com, sip@lists.research.bell-labs.com Subject: Re: [SIP] Second try : Questions about REGISTER References: <200005030000.TAA17220@b04a45.exu.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sean Olson wrote: > > > Personally, I wonder why we didn't just go ahead and include the user part > > in the request-URI. This would allow my request-chaining REGISTER to be > > fairly explicitly stated and solve lots of messiness. > > > > -- > > Dean > > > > I second that :) I've never understood the rationale behind excluding the user part in > the Request-URI of a REGISTER request. > This may well be worth doing; the motivation was that REGISTER is somewhat different in that you are not addressing the user directly, as in INVITE. If a registrar/proxy server were to ignore that REGISTER is special and needs to be handled locally, it would just send the request to whatever foo@domain translates to. -- 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 May 2 23:22:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13799 for ; Tue, 2 May 2000 23:22:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 60D744433B; Tue, 2 May 2000 23:16:44 -0400 (EDT) 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 0B98444336 for ; Tue, 2 May 2000 23:16:42 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue May 2 23:20:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F043D44344; Tue, 2 May 2000 23:07:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id CA82644341 for ; Tue, 2 May 2000 23:07:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4C3A852BB; Tue, 2 May 2000 23:07:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8E68D52AB for ; Tue, 2 May 2000 23:07:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 23:05:43 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue May 2 23:05:42 EDT 2000 Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA01797; Tue, 2 May 2000 23:06:58 -0400 (EDT) Message-ID: <390F9700.F3FA43D8@dynamicsoft.com> Date: Tue, 02 May 2000 23:03:28 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Jonathan Lennox Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Problem with the syntax of URI extension parameters References: <200005022203.SAA34631@conrail.cs.columbia.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit You would probably want to exclude "?" and "," from param-reserved: "?" - to eliminate the ambiguity with "?" that separates parameters from headers, "," - because URLs are allowed in certain headers and allowing commas in SIP URLs will make parsing those headers sometime impossible. Another observation: to be as backward compatible as possible the characters allowed in param-reserved should be a subset of those allowed in token. The intersection of reserved from RFC2396 and token from RFC2543 leaves us with the following param-reserved = "+" Also, note that unreserved in RFC2396 allows "(" and ")", while token does not. On the other hand, I don't think that many implementations will get broken if those extra characters are allowed. --- Igor Slepchin Jonathan Lennox wrote: > I think it'd be much more in the spirit of the generic URI syntax to have > other-param be defined like this: > > other-param = pname | pname "=" pvalue > pname = 1*paramchar > pvalue = 1*paramchar > paramchar = param-reserved | unreserved | escaped > param-reserved = "/" | "?" | ":" | "@" | "&" | "+" | "$" | "," > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 2 23:52:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14387 for ; Tue, 2 May 2000 23:52:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C7F64433B; Tue, 2 May 2000 23:46:45 -0400 (EDT) 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 969F444336 for ; Tue, 2 May 2000 23:46:42 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 2 23:50:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E0E6044344; Tue, 2 May 2000 23:37:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id B079D44341 for ; Tue, 2 May 2000 23:37:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7AC1252BB; Tue, 2 May 2000 23:37:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A734652B6 for ; Tue, 2 May 2000 23:37:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 2 23:35:47 EDT 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 2 23:35:47 EDT 2000 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 XAA00108; Tue, 2 May 2000 23:35:42 -0400 (EDT) Message-ID: <390F9E8E.10FAEAB1@cs.columbia.edu> Date: Tue, 02 May 2000 23:35:42 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Jonathan Lennox , sip@lists.research.bell-labs.com Subject: Re: [SIP] Problem with the syntax of URI extension parameters References: <200005022203.SAA34631@conrail.cs.columbia.edu> <390F9700.F3FA43D8@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > You would probably want to exclude "?" and "," from param-reserved: "?" > - to eliminate the ambiguity with "?" that separates parameters from Done. > headers, "," - because URLs are allowed in certain headers and allowing > commas in SIP URLs will make parsing those headers sometime impossible. As far as I know, all headers where URLs are allowed mandate the use of <> for URLs with commas or other "bad" characters. Any we missed? (Probably still a good idea to make it reserved; the pain is small compared to the confusion avoided.) > > Another observation: to be as backward compatible as possible the > characters allowed in param-reserved should be a subset of those allowed > in token. The intersection of reserved from RFC2396 and token from > RFC2543 leaves us with the following > > param-reserved = "+" Anybody object to this most restrictive coding? The only slight problem with being restrictive is that it makes hand-coding HTML pages with SIP URLs more painful. On the other hand, we haven't really defined any parameters likely to see $ or @. However, removing : doesn't work well, since we allow it in IPv6 numerical addresses in the maddr parameter. Would seem strange to force escaping here. > > Also, note that unreserved in RFC2396 allows "(" and ")", while token > does not. On the other hand, I don't think that many implementations > will get broken if those extra characters are allowed. > -- 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 May 3 00:38:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14773 for ; Wed, 3 May 2000 00:38:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEC154433B; Wed, 3 May 2000 00:32:44 -0400 (EDT) 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 4274E44336 for ; Wed, 3 May 2000 00:32:42 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 00:36:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id BEC9A44344; Wed, 3 May 2000 00:23:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 97CBA44341 for ; Wed, 3 May 2000 00:23:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6368E52BB; Wed, 3 May 2000 00:23:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8D2B852B6 for ; Wed, 3 May 2000 00:23:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 00:22:28 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 3 00:22:27 EDT 2000 Received: from dynamicsoft.com (1Cust120.tnt2.freehold.nj.da.uu.net [63.17.114.120]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01822; Wed, 3 May 2000 00:23:41 -0400 (EDT) Message-ID: <390FABFC.5C3C6092@dynamicsoft.com> Date: Wed, 03 May 2000 00:33:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Natarajan Kalpathy Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Content Lenght in responses References: <862568D4.00024F2D.00@mwgate02.mw.3com.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Natarajan Kalpathy wrote: > > Why is the Content Length field not mandatory in cases of SIP responses ??. Wont > it simplify the message processing in case of TCP. The current rfc2543bis draft > says > > "If a response does not contain a Content-Length, the client assumes that it > encompasses the remainder > of the UDP packet or the data until the TCP connection is closed, as applicable. > " > > Please clarify .... I believe this is the result of legacy HTTP, where Content-Length is not mandatory in responses. I also believe this is because CGI scripts that generate dynamic content wouldn't know the Content Length ahead of time, so just sending data, and then closing the connection, was the easiest way to determine message length. I can certainly envision placing of dynamic content in SIP responses, so this may prove useful for us as well. Processing of responses without content length is pretty simple anyway. It just means an additional counter that counts actual bytes read from the response. When the connection closes, this value is your content length. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 3 00:40:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14800 for ; Wed, 3 May 2000 00:40:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1421D44351; Wed, 3 May 2000 00:34:47 -0400 (EDT) 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 4C9284434D for ; Wed, 3 May 2000 00:34:42 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 00:38:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 07A2744345; Wed, 3 May 2000 00:25:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C3E8244341 for ; Wed, 3 May 2000 00:25:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 76DD052BB; Wed, 3 May 2000 00:25:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6472552B6 for ; Wed, 3 May 2000 00:25:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 00:24:20 EDT 2000 Received: from kevlar.softarmor.com ([63.64.250.82]) by dusty; Wed May 3 00:24:18 EDT 2000 Received: from dwillis (dwillis2.directlink.net [63.64.250.83]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id KAA04101 for ; Wed, 3 May 2000 10:25:57 -0500 Message-ID: <003401bfb4b7$75322a60$53fa403f@directlink.net> From: "Dean Willis" To: "IETF SIP" Date: Tue, 2 May 2000 23:24:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] Revised Minutes, SIP WG, IETF 47 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit These are the hopefully final minutes of the SIP WG at the 47th IETF in Adelaide. They vary from the draft in that the consensus seems to be that draft-campbell-sip-service-control-00.txt was not adopted as a WG item as previously reported, but that the authors were encouraged to submit it as an individual submission on informational track. If there are no other changes I will conclude the revision of minutes and post the final. ---- Minutes of SIP WG, IETF 47. Notes recorded by Tom Taylor. 1. Agenda Bashing ================= The proposed agenda was accepted. Presenters from Kyoto University asked to be added to the agenda. The request was denied because their draft had not been submitted in time to be published by the IETF. 2. Status ========= Dean Willis presented a summary of status of the WG work items, followed by a brief discussion of potential charter items. There was discussion as to whether the DCS drafts would be considered for adoption by the WG. The current drafts still have RFC2026 complienace issues preventing WG adoption as work items, but these issues may soon be resolved. The general consensus seems that several of the DCS drafts are likely to be adopted once the IPS is resolved. The WG indicated consensus to adopt several tasks as chartered WG activities, including: SIP server features (standards track) Call flows (informational) Session Timer (standards track) Reliability of provisional messages (standards track) SIP-T efforts: ISUP MIME types (standards) ISUP mapping (undetermined) Single Line Extension (undetermined) Guidelines for Extensions. As a general note regarding the management of the work of the WG: Jonathan Rosenberg is attempting to assemble teams around specific work items, with the proviso that individual participants should not be over-committed. The "single line extension" team is an example of this. 3. Summary of Current Discussion On The List ============================================ Jonathan Rosenberg summarized the status of discussion of a number of current issues. 3.1 draft-nair-sip-dhcp-00.txt No issues have been raised on the list, nor comments received from the DHCP WG. The fast-track procedure applied to this work appears to be acceptable to the SIP WG. 3.2 Content In INVITE Discussion in late December of how to include of content such as JPEG images in INVITEs brought out a number of points: -- whether to include the actual content, include it indirectly through provision of a URI, or include it indirectly as a media stream -- location of the content, in a header or in the body -- the need to identify how the content is to be used. Jonathan perceived no consensus on these items, due to lack of comment on specific proposals made to the list. 3.3 WWW-Authenticate Syntax There is a proposal before the list, but no comments have been received. 3.4 tel:// vs. sip:// URLs Jonathan emphasized the importance of the issue, discussion of which has stalled. He would like to see a new push to resolve it. 3.5 URL Parameters For Telephone Numbers A couple of issues have been discussed under this heading: how to indicate that the number shown is the result of an LNP lookup, and how to indicate private dialing plans. Again, Jonathan would like to see a renewed effort to resolve these issues. 3.6 To Quote Or Not To Quote: Digest-URI Robert Sparks commented that most implementations use quotes around the digest-URI. Usage for other fields is variable. He suggests that all fields be quoted. 3.7 Re-INVITE Glare Jonathan noted that three proposals are on the table for handling of coincident re-INVITEs. Scott Petrack noted the need for a solution that works with more than two parties. Jonathan responded that SIP states are shared only on a per-call-leg basis, except possibly in the case of multicast, so multileg coincidental invites may not be an issue. [A couple of points in Jonathan's charts were skipped because they are being considered by the SIP security task force.] 3.8 When To Send 183 Response Jonathan presented the rules for use of the 183 response which had come out of discussion on the list. A brief discussion followed, in which a problem with the first rule was noted and resolved. 3.9 Overlap Dialling Jonathan noted that there was no easy solution to the possibility of forking for a call in which overlap dialling is being used. David Oran suggested that when the gateway rejects the first call, it should return a contact which redirects all subsequent INVITEs to the same gateway. Jonathan noted that this changed the meaning of the Contact: header slightly, but its usage remains within acceptable bounds. 3.10 Early Media Criticality Jonathan noted a continuing unresolved issue of how to distinguish between critical and non-critical early media. In general Jonathan intends to put out notes to the list to stimulate further discussion of the open issues. 4. Status Of I-Ds (Jonathan Rosenberg)[charts] ====================================== 4.1 Caller Preferences (draft-ietf-sip-callerprefs-01.txt) Jonathan summarized a number of changes in the current draft. There have been no objections to the use of case-sensitive matching. The draft is due to go to the IESG, but Jonathan is looking for volunteeers to check it out first. 4.2 Supported: Header (draft-ietf-sip-serverfeatures-02.txt) The draft has undergone a major overhaul. The one open point had to do with use of the header with ACK. This has been fixed and the draft has been forwarded to the IESG. 4.3 Reliable Provisional Responses (draft-ietf-sip-100rel-00.txt) A number of open issues still remain. -- cumulative acknowledgements: looking for an application to justify inclusion of the mechanism -- response to PRACK: retain mechanism -- CANCEL for PRACK: disallow We are looking to pass this document to the IESG as a Proposed Standard by mid-April. 4.4 Guidelines For Authors Of SIP Extensions (draft-rosenberg-sip-guidelines-00.txt) Jonathan proposed that this be a WG work item. It would eventually become a BCP, but not for another year. For now it would be a living document as the WG accumulates experience. The sense of the meeting was to adopt the work item, but there were mixed views on how quickly it should be given formal status, with some arguing for near-term RFC status. This point will be taken to the list. Jonathan has volunteered to maintain the document if the WG chooses to make it a long-term project as he proposes. 4.5 Third-Party Call Control (draft-rosenberg-sip-3pcc-00.txt) This document has a number of dependencies, and various models of control are possible. In general the work does not involve an extension to SIP, but only a description of the usage of its mechanisms. For this reason Jonathan does not propose that it be a WG work item, but would like people to comment on it. 5. DCS Drafts ============= 5.1 Resource Reservation (Bill Marshall) [charts] (draft-manyfolks-sip-resource-00.txt) This draft came about through the compromise merger of draft-ietf-mmusic-qos-00.txt and draft-dcsgroup-sip-resource-01.txt. The two-stage INVITE has been discarded. SDP enhancements in support of QOS and security negotiation include two new attributes (a=qos: and a=security:), with syntax provided for confirmation that the requested attribute values have been granted. Extensions to SIP in support of the negotiation of these attributes are covered in the same document as the SDP changes, with AD approval. SIP extensions include use of a header indicating that preconditions have been met. The question was raised, whether there was any problem with using the a=qos: attribute with provisional responses to allow the invitee to set preconditions. Bill made the point that the first user of the attribute has to know whether the other end would understand it. 5.2 Caller Identity (Flemming Andreasen) [charts] (draft-dcsgroup-sip-privacy-01.txt) Flemming summarized changes in the draft. Earlier work has been extended to recognize the possibility of boundaries between proxies. In geneal, rather than requiring a nounary proxy to remove calling party information, any proxy may encrypt the field and list itself as an authenticator. A new header, "Remote-Party-ID", has been defined. The set of possible operator services has been generalized. Scott Petrack suggested that a specific tag for operator services might not be in the spirit of SIP. Jonathan agreed that an alternate approach might be possible. The basic idea, as always in SIP, is to define a small set of reusable features rather than a variety of specialized ones. 5.3 Distributing Call State (Bill Marshall) [charts] (draft-dcsgroup-sip-state-01.txt) The mechanism has changed completely since the previous draft, in an attempt to make it more general. The draft now takes care to distinguish between transaction state, connection state, and call state. The rules for including the "State" header have been simplified. There was a comment to the effect that the state information must include the information necessary to ensure that it is not used for a different call from the one which generated it. 5.4 Proxy-to-Proxy Extensions (Mike Mannette) [charts] (draft-dcsgroup-sip-proxy-proxy-01.txt) Mike reviewed the changes from the previous draft. LNP support has been provided and hostport is now a required field in the "Gate" header. The "Billing-Info" and "Billing-Id" headers are unchanged. 5.5 Media Authorization (B. Beser) [charts] (draft-dcsgroup-sip-call-auth-01.txt) This draft addresses the need for a per-call mechanism to authorize the flow of media. The new draft has been changed to focus only on the client. The former "DCS-Local-Gate" header has been renamed to "Media-Auth". The content has been generalized to hexadecimal. 6. Subscribe-Notify (Adam Roach) ========================================== (draft-roach-sip-subscribe-notify-00.txt) Motivation: there is a need for a central definition of concepts which have been mentioned in various documents. The draft formalizes the methods and headers associated with subscription and notification. Distinctions are made between call-related and resource-related subscriptions, with the latter typically being of interest to third parties. Rules are set down for notifications and for duration of subscriptions. The author attempted to avoid disruption to PINT, but it might be possible to combine the PINT work with this new material. Scott Petrack noted that PINT had spent a great deal of time working to make their mechanisms sufficiently generic. He urged Adam to review the PINT archives. Unsubscription proved to be a tricky topic, and PINT found it preferable to list events in bodies rather than in headers. Scott and Adam will discuss this further off-line. Henry Sinnreich asked what measures had been taken to coordinate with the Instant Messaging and Presence (IMPP) WG. Jonathan replied that IMPP is addressing a different problem and had already judged SIP to be unsuitable for their purposes. He also recalled that a general subscription/notification BOF was held, but nothing came out of it because the problem was too broad. Scott Petrack noted that PINT will change if necessary to conform to SIP. An example subscription/notification service was presented, where the caller is rung back when the callee becomes free. There are open issues where further work is required. Jonathan proposed that another task force be set up on the Egroup mail server, to refine the problem statement. Michael Thomas questioned whether SIP really needed an asynchronous method of completing a call when the current protocol can support a blocking approach. 7. Mobility (S. Baba) [charts] ========================= (draft-itsumo-sip-mobility-req-00.txt) The draft provides requirements, open issues, and relevant work items in SIP and other WGs. The requirements are organized on a functional basis. Addressing the charts, Lawrence Conroy asked what was meant by the requirement to "utilize" CDMA soft hand-off. He saw this as invisible at the IP level. The presenter pointed out that the process might involve multiple IP addresses for the same UA. This would represent a major extension to SIP. James Polk noted that the forthcoming Location Information BOF might be relevant to this problem. [end of first session] 8. Review Of Charter Work Items (Dean Willis) [charts] =============================== Dean asked for comments on the proposed work items before the WG chairs reviewed them and passed the results of the review on to the list. There were no comments. 9. INFO Method, Session Timer, 183 Session Progress (Steve Donovan) [charts] =================================================== 9.1 INFO Method Work on the INFO method, draft-ietf-sip-info-method-01.txt, is basically done. 9.2 Session Timer The Session Timer draft (draft-ietf-sip-session-timer-01.txt) underwent significant change to reflect the new "Supported" header. Some issues remain before WG Last Call: -- refreshing of the timer. Jonathan suggested that this be done by re-INVITE, rather than a new method. Agreed. -- Session-Expires header problematic in anything but INVITE -- will be allowed with INVITE only. -- Can a proxy add Required headers? -- could end up with multiple Required headers if the UAC also includes one. This doesn't seem to break anything, but there is an interaction with authorization. In the absence of comment from anyone but Jonathan, this should be checked out on the list. -- the question was asked: what happens if the called UA includes Session-Expires with a re-INVITE and it contradicts the one set by the calling UA? Steve suggested that it would be up to the implementation to sort this out. The list will be invited to comment. Next steps: -- agreed that this becomes an official WG work item -- submit shortly to WG Last Call. 9.3 183 Session Progress draft-ietf-sip-183-00.txt has a lot of dependencies, resulting in improved understanding of the issues. It may be used for early media and for pre-conditions. Summarizing the extensions involved: -- full session description bodies in 18x responses -- add the 183 response -- provide the "Session" header to indicate the purpose of the session description body The first two items are in 2543 bis already. It is proposed that the Session header draft be refined to narrow its focus, taking advantage of the 183 documentation. 10. Call Control (Robert Sparks) [charts] ================================ 10.1 Framework For Call Control Extensions (draft-campbell-sip-cc-framework-00.txt) Needs to be aligned with the guidelines. 10.2 Call Transfer (draft-sparks-sip-cc-transfer-00.txt) Proposes a new TRANSFER method (not BYE ALSO), which does not alter the original session. Open issues: -- name of the method. Jonathan interjected that he does not want to build protocols for specific services, hence the method should have a more abstract name and definition. Dean Willis suggested "Introduce". -- whether the method can carry bodies -- authentication. Dean Willis suggested an "Introduced-By" header, signed by the transferor. 10.3 Service Context -- Use of the SIP Request URI (draft-campbell-sip-service-control-00.txt) This is an informational draft proposing the transmission of service context through use of a distinctive Request-URI. Robert provided an example application and described the advantages of the mechanism. David Oran was unclear on the intent of the work. He noted that it takes the opposite approach to that of HTML, by using the left side of the URL rather than the right. The syntax conflict could make the result different depending on the server. Dean Willis pointed out that SMTP also uses the left hand side, and that web URLs lack the @ and therefore HAVE no left hand side. Robert responded that the URL is intended to be an opaque entity bound as a whole against a particular service. David agreed that under these conditions the format was acceptable. The authors were encouraged to submit this work for informational RFC status. This work was not adopted as a group effort of the SIP WG. 10.4 Call Flow Examples (Presentd by Robert Sparks) (draft-ietf-sip-call-flows-00a.txt) The draft has had a number of updates. Please forward any further flows to Alan Johnston (alan.johnston@wcom.com). Jonathan noted that the document is getting too large to handle easily. He proposes to farm out subsections to volunteers to review. Ideally they should simulate the flows to validate them. Alan Johnston will coordinate the work. There is an issue with dependencies on work in progress. The document will be partitioned so that the stable part is processed first. 11. IETF SIP MIB (David Walker) (draft-ietf-sip-mib-00.txt) Issue: the document is 70 pages long. Can this be reduced? It covers RFC 2543 plus the INFO method and the 183 response. Items are defined within configuration, statistics, and notification groups for each of the UAC, UAS, proxy, registrar, and redirect server, except that elements common to all of these are grouped separately. (Nothing has been defined as yet to be specific to the redirect server.) Concern: too many measurements. Discussion of this brought out the following: -- measurements should be defined only if there is a stated use for them -- they are used as a troubleshooting tool, but a message history tool would do a better job David will send a note to the list to provoke further discussion. Comments on how measurements are used will be welcome. The note will also raise a number of other questions for comment. The current draft contains a couple of known errors. 12. BCP For SIP to ISUP Mapping (Gonzalo Camarillo) [charts] (draft-camarillo-sip-isup-bcp-00.txt) This draft covers requirements, call flow examples, and the mapping of parameters between the two protocols. Gonzalo went over the changes to the draft: -- new name -- additional extension: umbrella REQUIRE -- refinement of scope -- a discussion of SIP bridging between ISUP networks -- corrections to the handling of overlap signalling -- added examples. He presented a walk-through of the overlap signalling case. There is a lot of messaging, but, unlike in the previous draft, it works. There is an open issue of how to control routing of overlap signalling in the case of a stateless proxy forwarding to loadsharing MGCs. A question was asked: how is connection redundancy handled -- for example, UA multihoming. What if the successive messages arrive at different answers. The reply was that this issue was out of scope of the draft. Jonathan remarked that SCTP transport for SIP is a topic for the future. Gonzalo concurrently presented a report on the status of the SIP-T work. It was noted that of the SIP-T work, the highest priority is to obtain approval of the ISUP MIME types document. This is currently planned for May 2000. 13. SIP Mapping Of MLPP (James Polk) [charts] (draft-polk-sip-mlpp-mapping-00.txt) There is a mismatch between SIP "priority" levels and MLPP levels. The draft proposals are to add a level and add administrative hooks. Jonathan remarked that the standard is not the place to specify the administrative hooks -- they belong in an RFP. Subsequent discussion brought out two points: -- added priority level in RFC 2543bis -- additional document describing operation of MLPP. This would cover a number of items besides SIP, so it should not be a SIP WG document. Jonathan also wondered whether MLPP really impacts SIP except at the gateway, since it is concerned with preemption of limited call resources in the face of higher-priority demand and IP resources are not so obviously limited as circuits. Brian Rosen disagreed, pointing out that MLPP is not only about preeemption. The outcome of the discussion was consensus to discuss adding another priority level to 2543bis, or possibly adding "token" to the grammar allowing arbitrary extension. This will require list review. James Polk may submit a detailed fraft showing how the SIP priority levels can be used to implement MLPP requirements. 14. Update On ISUP MIME Types (Lyndon Ong) (draft-ong-sip-qsig-mime-00.txt) The draft has one open issue: the amount of ISUP version information required. Followup is occuring in the SIP-T subteam and will be reviewed on the main list when ready. 15. SIP and QOS (Henry Sinnreich) [charts] (draft-sinnreich-sip-qos-osp-01.txt) Henry presented a list of "to do" items associated with the work. He hypothesized that a new WG may be required. As evidence of this he cited the need for a framework, within which different QOS models might operate. Radhika Roy mentioned that ITU-T Study Group 16 is also doing QOS work, and the two groups could share their results. Henry agreed that this was possible. Patrice Calhoun asked about the relationship between QOS and OSP (Open Settlement Protocol, which appeared on Henry's charts). Henry indicated that OSP was relevant because it supports the clearing house model of settlements, and the latter differs from the AAA WG model. Melinda Shore remarked that overall (thinking also of DCS) there seemed to be some strange QOS work going on, driven by charging models. Hooks within SIP are in scope for SIP WG discussion, but the general topic of QOS for VoIP is out of scope. Continuing in his presentation, Henry presented call flows showing the tight coupling between signalling, QOS, and AAA. Jonathan remarked again that ONLY changes required to SIP are within the SIP WG's scope. Dave Oran observed that DCS covers the "push model" of QOS: policy is pushed to the enforcement point. There is a need to develop a system for the pull model, with open security issues standing in the way. Dave proposed COPS-PR for this role. Dean Willis suggested that perhaps the Transport Area WG could tackle the larger problem. Jonathan proposed discussing the matter with the ADs. 16. SIP Through Firewalls and NATs (Jonathan Rosenberg) [charts] (draft-rosenberg-sip-firewalls-00.txt) Jonathan noted that the topic of firewall/NAT traversal is being covered by the foglamps BOF. The question is whether the SIP WG wants to do an Informational RFC on the specific topic of SIP operation through these barriers. Dean Willis suggested that the question of whether this work belongs in SIP is of the same order as whether MLPP does -- that is, both are enablements for SIP within specific sectors. There was a weak hum in favour of the work item. 17. Usage of TRIP For Gateway Registration (Jonathan Rosenberg) (draft-rs-trip-gw-00.txt) This was simply an alert to the topic, which had been raised in the meeting of the IPTEL WG the previous day. 18. Transferring User Control Information In SIP REGISTER Payloads (Jonathan Rosenberg) (draft-lennox-sip-reg-payload-00.txt) We need a way to pass scripts from the client to the server. This draft is the same as the original version a year ago, with minor changes. There are several open issues. Jonathan asked "Should this be a SIP work item?", which started a lively discussion. Radhika Roy suggested there was a relationship to and potential impact on mobility; Jonathan disagreed. Lawrence Conroy wondered how the scripts would be authenticated. Dean Willis mentioned several approaches that have been suggested. Dean put the question: "even with the other alternatives, is it useful to do this function via REGISTER?" There was a slight hum in favour, no opposition, with most registering no opinion. The work was accepted subject to approval on the list. 19. Finding A SIP Server With SLP (James Kempf) (draft-kempf-sip-findsrv-00.txt) The intention is to add a template to the IANA service type registry. Motivation: there are several ways to locate a SIP server through DNS -- for example, by use of a naming convention. The method presented allows location by characteristics. This is useful because different proxies in a domain can have different characteristics. The approach taken is to have one SLP abstract service type: "service-sip", with two concrete service types. Jim presented an example: find a registrar supporting CPL. An open issue is how to handle incoming calls. With other methods of DNS usage, one can parse down the hierarchy of server names. With SLP it may be necessary to use SIP forking or multicast. Should this be a WG work item or an individual draft? IANA approval requires RFC documentation and approval by Eric Guttman (servloc Chair). Comments on the draft can go to Jim directly or to the list. Jonathan noted that this is one of many possible methods, but that's OK. There is certainly no point in discussing whether this work should go forward as opposed to some other approach. The consensus was to not adopt this as a WG task at this time, but to follow the work as it matures and reconsider at a futue point. 20. CGI Interface (Jonathan Rosenberg) (draft-lennox-sip-cgi-03.txt) The draft is being cleaned up. A couple of issues have been resolved. There are alternative methods for transfer of the CGI scripts. There appears to be no intent to make this a WG item at this time. 21. Distributed Multipoint Conferences Using SIP (Jeff Mark) [charts] (draft-mark-sip-dmcs-00.txt) Jeff provided some examples, showing manipulation of full mesh conferences. Is there SIP interest in further such full mesh work? Jonathan noted that conference control is not part of the SIP WG mandate. The problem of topology management is overly complicated because call control should be separated from link state propagation. The latter is not something SIP is good at. Jonathan will organize a first pass at rearchitecting the proposal, but there are other approaches to multi-party conferencing that may prove worth discussing. -- Dean Willis dwillis@greycouncil.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 May 3 00:50:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14846 for ; Wed, 3 May 2000 00:50:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7C7E44352; Wed, 3 May 2000 00:44:44 -0400 (EDT) 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 4BA0044350 for ; Wed, 3 May 2000 00:44:42 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 00:49:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1C82244346; Wed, 3 May 2000 00:35:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E95BB44341 for ; Wed, 3 May 2000 00:35:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id AF3AB52BB; Wed, 3 May 2000 00:35:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D62BF52B6 for ; Wed, 3 May 2000 00:35:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 00:34:42 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 3 00:34:41 EDT 2000 Received: from dynamicsoft.com (1Cust120.tnt2.freehold.nj.da.uu.net [63.17.114.120]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01839; Wed, 3 May 2000 00:35:53 -0400 (EDT) Message-ID: <390FAED8.3187B7B5@dynamicsoft.com> Date: Wed, 03 May 2000 00:45:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Sean Olson , dean.willis@wcom.com, sip@lists.research.bell-labs.com Subject: Re: [SIP] Second try : Questions about REGISTER References: <200005030000.TAA17220@b04a45.exu.ericsson.se> <390F8BCE.932883E5@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Sean Olson wrote: > > > > > Personally, I wonder why we didn't just go ahead and include the user part > > > in the request-URI. This would allow my request-chaining REGISTER to be > > > fairly explicitly stated and solve lots of messiness. > > > > > > -- > > > Dean > > > > > > > I second that :) I've never understood the rationale behind excluding the user part in > > the Request-URI of a REGISTER request. > > > > This may well be worth doing; the motivation was that REGISTER is > somewhat different in that you are not addressing the user directly, as > in INVITE. If a registrar/proxy server were to ignore that REGISTER is > special and needs to be handled locally, it would just send the request > to whatever foo@domain translates to. I'm not sure I see what is gained by adding a user portion. What is the semantic of having a user portion in the request URI? This still doesn't change how a proxy looks up registrations when an INVITE request is received (still based on request URI), which is what Dean is asking for. I agree completely with Dean that there is value in being able to route based on the To field for certain things. It is my belief that out of the ordinary routing and request handling services, in general, will require programmability in proxies (though CPL, or more likely CGI or servlets). I can think of a reason to making a routing decision based on almost any header field in the request. Rather than specifying these things in the protocol, leaving them to custom applications gives you maximum flexibility. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 3 01:08:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15396 for ; Wed, 3 May 2000 01:08:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C62CD44340; Wed, 3 May 2000 01:02:44 -0400 (EDT) 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 59E0844336 for ; Wed, 3 May 2000 01:02:42 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 01:06:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E5D2044344; Wed, 3 May 2000 00:53:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BF1D844341 for ; Wed, 3 May 2000 00:53:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8A94952BB; Wed, 3 May 2000 00:53:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C73E952AB for ; Wed, 3 May 2000 00:53:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 00:51:06 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 3 00:51:06 EDT 2000 Received: from dynamicsoft.com (1Cust120.tnt2.freehold.nj.da.uu.net [63.17.114.120]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01852; Wed, 3 May 2000 00:52:19 -0400 (EDT) Message-ID: <390FB2B2.9986E0EE@dynamicsoft.com> Date: Wed, 03 May 2000 01:01:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Igor Slepchin , Jonathan Lennox , sip@lists.research.bell-labs.com Subject: Re: [SIP] Problem with the syntax of URI extension parameters References: <200005022203.SAA34631@conrail.cs.columbia.edu> <390F9700.F3FA43D8@dynamicsoft.com> <390F9E8E.10FAEAB1@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Igor Slepchin wrote: > > > > You would probably want to exclude "?" and "," from param-reserved: "?" > > - to eliminate the ambiguity with "?" that separates parameters from > > Done. > > > headers, "," - because URLs are allowed in certain headers and allowing > > commas in SIP URLs will make parsing those headers sometime impossible. > > As far as I know, all headers where URLs are allowed mandate the use of > <> for URLs with commas or other "bad" characters. Any we missed? > (Probably still a good idea to make it reserved; the pain is small > compared to the confusion avoided.) I agree the , should be escaped to avoid confusion. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 3 06:22:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28049 for ; Wed, 3 May 2000 06:22:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0FBE044351; Wed, 3 May 2000 06:16:43 -0400 (EDT) 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 8F7D844340 for ; Wed, 3 May 2000 06:16:40 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 06:20:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 20B4644344; Wed, 3 May 2000 06:07:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id EA52844341 for ; Wed, 3 May 2000 06:07:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B126352C4; Wed, 3 May 2000 06:07:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CA5E852B6 for ; Wed, 3 May 2000 06:07:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 06:06:24 EDT 2000 Received: from imc21.ex.nus.edu.sg ([137.132.14.62]) by dusty; Wed May 3 06:06:23 EDT 2000 Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id <26GSFQ3P>; Wed, 3 May 2000 18:06:22 +0800 Message-ID: <30A14FB41CC5D311854D00508B5EEF0201ED5563@exs23.ex.nus.edu.sg> From: Ge Yu To: Jonathan Rosenberg , Shail Bhatnagar , "'Alexandru Gavrilescu'" Cc: SIP IETF Subject: RE: [SIP] Second try : Questions about REGISTER Date: Wed, 3 May 2000 18:06:19 +0800 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, friends, As I know through 16.1 of RFC 2543, the registration process is as follows: 1. Watson firstly sends the REGISTER request to the server at bell-tel.com, with Contact: Watson@example.com. That is, he hasn't contacted with the server at example.com ahead of REGISTER. So what happens if another Watson@example.com has been registered in example.com domain? 2. Watson registers to the server at example.com, which confirms the registration, through the process the server at example.com knows where to forward the INVITE to Watson. 3. the server at example.com contacts with Registar( or it acts as Registar itself), and stores the updated URL in Location server. 4. the sender's proxy server enquiries the location server, knows the current URL of recepient and forwards the INVITE to example.com, which transfers it to Watson. Anything missed? Very appreciated with your kindly feedback. Ge Yu > ---------- > From: Alexandru Gavrilescu[SMTP:alexang@Exchange.Microsoft.com] > Sent: Wednesday, May 03, 2000 2:48 AM > To: Jonathan Rosenberg; Shail Bhatnagar > Cc: SIP IETF > Subject: RE: [SIP] Second try : Questions about REGISTER > > > I have a question regarding Jonathan's answer to the Shail's third > question. > Do we assume that tawatson has an account created for himself at > example.com or he is just a visitor at example.com? > I assume the first. > What would be the behaviour is tawatson@bell-tell.com would be just a > visitor at example.com? > > > -----Original Message----- > From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com] > Sent: Monday, May 01, 2000 9:58 PM > To: Shail Bhatnagar > Cc: SIP IETF > Subject: Re: [SIP] Second try : Questions about REGISTER > > > > > Shail Bhatnagar wrote: > > > > In section 16.1 of RFC2543bis there is an example of Registration. I > > have > > a couple of questions about this scenario. I would appreciate any > > responses. > > > > 1) What would be the To header of the REGISTER that T. Watson sends to > > the registrar at example.com. Would it be tawatson@example.com or > > tawatson@bell-tel.com ?? As per the description in section 4.2.6, To > > header > > domain could be different from the domain of the Request-URI in the > > REGISTER. > > Most likely tawatson@example.com. This is because if some UAC or proxy > wants to send a request to tawatson@example.com, it will use DNS to find > the SIP server for example.com, and forward the request there. As a > result, watson will want to register tawatson@example.com with the > server for which requests to example.com will be routed. The spec does > not prohibit registering tawatson@bell-tel.com with example.com. > However, example.com is not likely to receive requests with domains of > bell-tel.com in the request URI. > > > > > 2) Let us say x@bell-tel.com (From: x@bell-tel.com) sends an INVITE to > > the > > proxy at bell-tel.com and the Request-URI is INVITE watson@bell-tel.com. > > > As per the latest registration, the Contact is tawatson@example.com, so > > the proxy at bell-tel.com rewrites the Request-URI and sends it to the > > proxy at example.com - INVITE tawatson@example.com. Now what is the > > search > > key at the registrar - is it user@domain or simply user. If it is simply > > > user, > > then domain of To header in REGISTER is meaningless. If it is > > user@domain, > > then To header of the REGISTER sent to the registrar at example.com must > > > be > > tawatson@example.com. > > Thats your choice. If your proxy only handles a single domain, using > user alone as a lookup key into your database is fine. If your proxy > handles multiple domains, you will want to use the complete user@host. > > > > > > 3) What if there already exists a user tawatson at the domain > > example.com. > > Should the registrar at example.com reject the registration ?? If yes, > > what response code should be used ?? > > No, the new Contact would be added to the existing registration. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Wed May 3 07:01:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28642 for ; Wed, 3 May 2000 07:01:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C62C4434B; Wed, 3 May 2000 06:56:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by lists.bell-labs.com (Postfix) with ESMTP id 854D144340 for ; Wed, 3 May 2000 06:56:12 -0400 (EDT) X-Envelope-Sender-Is: Pedro.Pedrosa@lis2.siemens.pt (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e43B1X923712; Wed, 3 May 2000 13:01:33 +0200 (MET DST) Received: from siepor43.siemens.pt ([180.142.222.243]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e43B1V911951; Wed, 3 May 2000 13:01:32 +0200 (MET DST) Received: by siepor43.net.siemens.pt with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 11:55:29 +0100 Message-ID: <753C243100F8D211B15C0800060D9D6EC3C2CF@siepor43.net.siemens.pt> From: Pedro Pedrosa To: Peter Blatherwick , "'hiren.shah@wipro.com'" , sip Subject: RE: [SIP] SIP/MGCP Date: Wed, 3 May 2000 11:55:29 +0100 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA28642 Hello, Is there any mailing list like the one we have for SIP? It would be highly interesting! How can I join? Best Regards Pedro Pedrosa -----Original Message----- From: Peter Blatherwick [mailto:blather@nortelnetworks.com] Sent: Terça-feira, 25 de Abril de 2000 15:11 To: 'hiren.shah@wipro.com'; sip Subject: RE: [SIP] SIP/MGCP Hiren: Please join the Megaco WG discussion, since that is the IETF Standards Track direction for gateway control. Megaco/H.248 Protocol is the international standard in this area, a joint effort between IETF Megaco and ITU SG-16. WG Charter, list instructions etc can be found at: http://www.ietf.org/html.charters/megaco-charter.html E-mail list archive is at: http://standards.nortelnetworks.com/archives/megaco.html Regards, Peter Blatherwick -----Original Message----- From: hiren.shah@wipro.com [ mailto:hiren.shah@wipro.com ] Sent: Tuesday, April 25, 2000 08:57 To: sip Subject: [SIP] SIP/MGCP Hi all nara and hemant have really cleared my doubts regarding the use of SIP in MGCP protocol.Thanks a lot. This is a bit off the line but can anyone direct me to a MGCP discussion forum. Basically i am doing some research in MGCP and SIP. regards Hiren _______________________________________________ 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 May 3 07:05:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28674 for ; Wed, 3 May 2000 07:05:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B8B64435E; Wed, 3 May 2000 06:59:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by lists.bell-labs.com (Postfix) with ESMTP id 953FE4435D for ; Wed, 3 May 2000 06:59:23 -0400 (EDT) X-Envelope-Sender-Is: Pedro.Pedrosa@lis2.siemens.pt (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e43B4i925072; Wed, 3 May 2000 13:04:44 +0200 (MET DST) Received: from siepor43.siemens.pt ([180.142.222.243]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e43B4h913639; Wed, 3 May 2000 13:04:43 +0200 (MET DST) Received: by siepor43.net.siemens.pt with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 11:58:41 +0100 Message-ID: <753C243100F8D211B15C0800060D9D6EC3C2D8@siepor43.net.siemens.pt> From: Pedro Pedrosa To: Pedro Pedrosa , Peter Blatherwick , "'hiren.shah@wipro.com'" , sip Subject: RE: [SIP] SIP/MGCP Date: Wed, 3 May 2000 11:58:41 +0100 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA28674 Hello, Forget it! I have found out how! Best Regards Pedro Pedrosa -----Original Message----- From: Pedro Pedrosa [mailto:Pedro.Pedrosa@lis2.siemens.pt] Sent: Quarta-feira, 3 de Maio de 2000 12:55 To: Peter Blatherwick; 'hiren.shah@wipro.com'; sip Subject: RE: [SIP] SIP/MGCP Hello, Is there any mailing list like the one we have for SIP? It would be highly interesting! How can I join? Best Regards Pedro Pedrosa -----Original Message----- From: Peter Blatherwick [mailto:blather@nortelnetworks.com] Sent: Terça-feira, 25 de Abril de 2000 15:11 To: 'hiren.shah@wipro.com'; sip Subject: RE: [SIP] SIP/MGCP Hiren: Please join the Megaco WG discussion, since that is the IETF Standards Track direction for gateway control. Megaco/H.248 Protocol is the international standard in this area, a joint effort between IETF Megaco and ITU SG-16. WG Charter, list instructions etc can be found at: http://www.ietf.org/html.charters/megaco-charter.html E-mail list archive is at: http://standards.nortelnetworks.com/archives/megaco.html Regards, Peter Blatherwick -----Original Message----- From: hiren.shah@wipro.com [ mailto:hiren.shah@wipro.com ] Sent: Tuesday, April 25, 2000 08:57 To: sip Subject: [SIP] SIP/MGCP Hi all nara and hemant have really cleared my doubts regarding the use of SIP in MGCP protocol.Thanks a lot. This is a bit off the line but can anyone direct me to a MGCP discussion forum. Basically i am doing some research in MGCP and SIP. regards Hiren _______________________________________________ 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 May 3 11:12:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03983 for ; Wed, 3 May 2000 11:12:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB6DB44343; Wed, 3 May 2000 11:06:53 -0400 (EDT) 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 23FC644340 for ; Wed, 3 May 2000 11:06:51 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA22431 for ; Wed, 3 May 2000 10:12:12 -0500 (CDT) Received: from lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA19031 for ; Wed, 3 May 2000 10:11:58 -0500 (CDT) Received: from lmc35.lmc.ericsson.se (lmc35.lmc.ericsson.se [142.133.16.175]) by lmc.ericsson.se (8.9.2/8.9.2) with ESMTP id LAA10504 for ; Wed, 3 May 2000 11:12:01 -0400 (EDT) Received: from lmc.ericsson.se (lmcpc118309.pc.lmc.ericsson.se [142.133.11.153]) by lmc35.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KC6J5H5B; Wed, 3 May 2000 11:10:43 -0400 Message-ID: <3910416A.6728467@lmc.ericsson.se> Date: Wed, 03 May 2000 11:10:34 -0400 From: "Mathieu Gervais (LMC)" Organization: LMC, Ericsson Research Canada X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; U) 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 URL support in Mozilla : sip not official URL scheme? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi all, I just posted a Request For Enhancement in Bugzilla, the Mozilla bug database. See http://bugzilla.mozilla.org/show_bug.cgi?id=37637 Comments about the RFE where added, from a Mozilla developer, saying SIP "is not on the list" of official URL schemes @ ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes (see http://www.iana.org/numbers.htm#U). Why isn't sip there? Is the registration of the sip url scheme with IANA "in process"? See also "Registration Procedures for URL Scheme Names" @ http://www.rfc-editor.org/rfc/bcp/bcp35.txt Feel free to add comments in bugzilla, but keep in mind it's a bug database, not a discussion forum. Thanks, Mathieu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 3 11:18:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04094 for ; Wed, 3 May 2000 11:18:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A76F944365; Wed, 3 May 2000 11:11:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id E013F44343 for ; Wed, 3 May 2000 11:11:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24671; Wed, 3 May 2000 09:16:52 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA05940; Wed, 3 May 2000 08:16:50 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA06215; Wed, 3 May 2000 08:16:49 -0700 (PDT) Message-Id: <200005031516.IAA06215@nasnfs.eng.sun.com> Date: Wed, 3 May 2000 08:19:33 -0700 (PDT) From: James Kempf Reply-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Sounder_of_Swine_044_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Subject: [SIP] Applicability of IP Mobility to CDMA Soft Handoff Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --Sounder_of_Swine_044_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ctfkkmfiDsXoPrUMStI7WQ== There has been some discussion on the mobile IP and SIP lists about replacing CDMA soft handoff with IP mobility mechanisms. The attached draft, authored by Pete McCann, Phil Roberts, and myself, attempts to explain how a CDMA RAN works and why soft handoff is not a promising candidate for replacing with IP mobility mechanisms in the near term. In contrast, the analysis is not applicable to hard handoff, which is a potential candidate for replacing with IP mobility. We have submitted this to the drafts alias as an individual contribution Comments are welcome. jak --Sounder_of_Swine_044_000 Content-Type: TEXT/plain; name="draft-kempf-cdma-appl-00.txt"; charset=us-ascii; x-unix-mode=0664 Content-Description: draft-kempf-cdma-appl-00.txt Content-MD5: QLFWjD/x2rxby7zjR/HDMQ== INTERNET DRAFT James Kempf Category: Informational Sun Microsystems, Inc. Title: draft-kempf-cdma-appl-00.txt Peter McCann Date: April 2000 Lucent Technologies Philip Roberts Motorola, Inc. IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft Handoff Status of this Memo This document is an individual contribution for consideration by the Mobile IP Working Group of the Internet Engineering Task Force. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 2000. All Rights Reserved. Kempf, McCann, Roberts expires October 2000 [Page 1] INTERNET DRAFT April 2000 Abstract Recently, there have been a variety of proposals submitted to the Mobile IP Working Group and to other IETF working groups for IP mobility solutions that seek to enhance or replace mobile IP. These proposals, often characterized as micromobility or fast handoff, are addressed primarily at the perceived need of multimedia sessions such as video or voice over IP for faster handoff between radio base stations, and are primarily directed at real time multimedia traffic in 3rd generation cellular access networks. In this paper, we discuss the design of CDMA radio access networks (RANs) and the applicability of IP mobility to soft handoff in a CDMA RAN. We attempt to show that given current IP routing algorithms and the constraints on a CDMA RAN, IP mobility solutions have little, if any, role to play in handoff within the RAN. In contrast, an IP mobility solution is likely to play a big role in fast handoff between RANs, also called hard handoff. While future developments in IP networking may change this situation, IP mobility in CDMA networks currently seems to apply only when the mobile node roams between RANs rather than between base stations within a RAN. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 RAN Architecture and Characteristics 4.0 Applicability of IP Mobility to Soft Handoff 5.0 Applicability of IP Mobility to Hard Handoff 6.0 Future Prospects for IP Mobility in the CDMA RAN 7.0 Summary 8.0 References 9.0 Authors' Addresses 10.0 Full Copyright Statement 1.0 Introduction Mobile IP [1] allows IP hosts that change their point of attachment to the network to keep their IP address as they change from their home subnet to other subnets. Recently, there have been a variety of proposals advanced for augmenting or replacing mobile IP in access networks for cellular telephony systems. These proposals are often characterized as supporting micromobility or fast handoff, and are directed towards real time multimedia streams in 3rd generation cellular networks (see [2] [3] [4] [5] and [7]). While these proposals may have some applicability if handoff between RANs is very frequent, their utility is lessened in the presence of Kempf, McCann, Roberts expires October 2000 [Page 2] INTERNET DRAFT April 2000 link-layer mobility like that offered by today's TDMA and CDMA systems. In fact if the link-layer offers transparent mobility throughout a given domain these proposals do not contribute anything since they are essentially intra-domain mobility management protocols. As cellular networks evolve towards more pervasive IP technologies, mobility for traffic within those networks must accommodate some level of movement of IP traffic. In this paper, we discuss CDMA radio access networks and why IP mobility solutions (including mobile IP) are not applicable to soft handoff in a CDMA radio access network. In effect, the CDMA RAN network with soft handoff is an application layer transport and mobility mechanism, and therefore not an appropriate candidate for moving into the network layer. In contrast, IP mobility solutions that are directed at improving handoff performance within the core network, often called hard handoff, are likely to play an important role in enhancing the performance of IP networking for CDMA (see [6] for an example). 2.0 Terminology mobile terminal A mobile IP host. In mobile IP terminology, this is called the mobile node. base station A fixed, land-based radio transmitter and receiver, used to provide cellular telephony radio coverage in a limited geographic area. A mobile terminal may be in contact with one or more base stations at a time in CDMA networks. Also called the Base Transceiver Station (BTS) or Node B. RAN The radio access network. This is a wired network that sits between a collection of base stations and the core, wired telephone network. The RAN in CDMA systems is involved in real-time distribution and collection of physical layer radio frames to and from base stations, a topic that is discussed in the next section. soft handoff The process by which a moving CDMA mobile terminal is transferred between one base station or set of base stations to another within the radio access network. Soft handoff is typically very fast (on the order of 20 ms) and has a low probability of dropping ongoing real time connections. hard handoff The process by which a moving mobile terminal is transferred Kempf, McCann, Roberts expires October 2000 [Page 3] INTERNET DRAFT April 2000 between one cellular service provider's network and another or between two RANs that do not share a direct connection within a provider's network. Hard handoffs have a higher probability of connection droppage, and are slower (usually 100 ms or more). macrodiversity A term used to describe the fact that within the CDMA RAN, there is no single octet stream corresponding to the data that arrives at or is sent by the mobile terminal. Macrodiversity results because the mobile terminal can be in contact with more than one base station at a time. frame selector A combination software/hardware unit at the gateway to the RAN that combines the multiple octet streams from multiple base stations in contact with a single mobile terminal into a single octet stream. A similar process happens at the mobile terminal. Also called the macrodiversity combiner or Selection and Distribution Unit (SDU). RAN gateway A functional unit positioned between the RAN and the core network. The RAN gateway includes the frame selector, in addition to functional units that perform soft handoff and radio frame processing. Also called the Base Station Controller (BSC) or Radio Network Controller (RNC). radio frame A short (usually 20 millisecond) unit of transmission at the physical radio layer used to transmit data over the air to and from the mobile terminal. The frames do not contain complete IP packets, but rather contain small sections of octet stream data that must be framed by a higher layer protocol (such as PPP) to form IP packets. On a basic fundamental data rate channel one radio frame contains about 20 octets. Radio frames may be retransmitted a small number of times to increase the reliability of the octet stream transport. This is performed by a negative- acknowledgement protocol known as the Radio Link Protocol (RLP). 3.0 RAN Architecture and Characteristics A RAN consists of a RAN gateway connected to one or more base stations. In the network to mobile terminal (forward) direction, the RAN gateway performs the following functions: 1) Receive packets from the core network destined to the mobile terminal, Kempf, McCann, Roberts expires October 2000 [Page 4] INTERNET DRAFT April 2000 2) Process those packets into radio frames, 3) Replicate the radio frames and transmit copies to base stations that are currently in contact with the mobile terminal in a way such that the frames arrive at each base station in a timely fashion, 4) Manage the retransmission of individual radio frames when negative acknowledgements are received. In the mobile terminal to network (reverse) direction, the RAN gateway performs the following functions: 1) Collect copies of the radio frames fowarded by base stations that are currently in contact with the mobile terminal, 2) Combine these (possibly errorful) copies into one (hopefully error-free) radio frame, 3) From the resulting radio frame stream, synthesize an outgoing octet stream of packets for the core network. In both directions, the RAN gateway performs the following function: 1) Manage the power with which mobile nodes and base stations are transmitting, so as to maintain a low error rate while at the same time minimizing the transmitted power and therefore interference among different transmitters (and drain on the mobile terminal's battery). 2) In concert with the mobile terminal, manage the set of base stations with which a mobile terminal is in contact such that the quality of the radio signal is maintained as the mobile terminal moves. The use of multiple base stations to transmit and receive the same radio frames to and from the mobile node at the same time is known as "macrodiversity" and can help to improve the reliability of the wireless link. Note that some of the base stations may be owned by a neighboring RAN and this necessitates a RAN-to-RAN interface to carry the radio frames. The following figure illustrates the architecture and how the CDMA Kempf, McCann, Roberts expires October 2000 [Page 5] INTERNET DRAFT April 2000 RAN network works: Core Network ^ | incoming/outgoing octet stream | from/to corresponding node (129.142.68.79) | V +-----------------------------------------------------+ | RAN Gateway | | | | +-------------+ +-----------+ +----------+ | | | | | | | | | | | Frame | | Frame | | Soft | |----------- | | Selection | | Splitting | | Handoff | | to another | | | | | | Control | | RAN Gateway | +-------------+ +-----------+ +----------+ | | | | +---------------+ | | | | | | | Radio Frame | | | | Processing | | | | | | | +---------------+ | | | +-----------------------------------------------------+ | | | | * | | | | * | | ... | | * radio | | | | * frames | | | | * | | | | * +---------+ +---------+ +---------+ +---------+ | Base | | Base | | Base | | Base | | Station | | Station | | Station | | Station | | B1 | | B2 | | B42 | | B43 | +---------+ +---------+ +---------+ +---------+ \ | \ V \---------> | ----- / \ ----- ----- 162.42.42.42 | mobile terminal|( ---> ------------------ ( ) ( ) Kempf, McCann, Roberts expires October 2000 [Page 6] INTERNET DRAFT April 2000 The links between the RAN gateway and the base stations are typically point to point links today, though provisions exist in the 3rd generation standards for switched networks. In the above figure, a mobile terminal with IP address 162.42.42.42 is corresponding with a host having the IP address 129.142.68.79, through a CDMA cellular network. The mobile terminal is in contact with two base stations, B1 and B2. The RAN gateway takes incoming packets from 129.142.68.79 and splits them into two streams that it sends to base stations B1 and B2. A mobile terminal can be in communication with up to 3 and, in some CDMA systems, up to 6 base stations at a time. When the multiple octet streams are received at the mobile terminal, the mobile terminal performs a sophisticated combination of the multiple packet streams at L1 to deliver the end packet to the application. Packets flowing in the other direction, from 162.42.42.42 to 129.142.68.79, are put into an octet stream which is then divided into radio frames. Each radio frame is received by B1 and B2 and delivered to the frame selector in the RAN gateway. The frame selector performs signal processing on the incoming radio frames and produces a single frame that is then sent to the re-sequencing buffer where the octet stream is re-created. The IP packets are formed from the octet stream and transmitted into the core IP network. An important point to note about the RAN is that, even if the RAN itself is running IP, routing in the RAN does not use the mobile's IP address. In fact, the IP packets sent by the mobile terminal are not tunneled through the RAN nor do they necessarily appear in a form that would be recognizable using a packet sniffer. The packets in the RAN contain radio frames that have been highly processed into a form that is extremely efficient for the base stations to handle and that efficiently uses radio spectrum, including compensations for the inherently lossy nature of the radio medium. On the forward leg to the mobile terminal, because the delay and jitter constraints between multiple base stations transmitting to the same mobile terminal are so tight (5ms to 80ms), the RAN gateway essentially puts out streams of radio frames that the base station can quickly pull off the wire and transmit over the air. On the reverse leg from the mobile terminal, the base station simply pulls the radio frames off the air and puts them on the wire without any further processing. The RAN gateway's radio frame processor is responsible for making sure that the jitter and delay constraints are met, and for processing packets from the core network into radio frames. Kempf, McCann, Roberts expires October 2000 [Page 7] INTERNET DRAFT April 2000 When the mobile terminal begins to move out of range of stations B1 and B2, the RAN gateway adds and deletes base stations from the set currently serving the mobile node. This process is called soft handoff. Note that new base stations may belong to a neighboring RAN which requires closely-coupled RAN-to-RAN interaction. The real time constraints on soft handoff are extremely tight. All base stations involved in soft handoff must transmit the command for the mobile to move at the same time. North American cellular networks use the Global Positioning System as a time source to assure that these timing constraints are met. As shown in the figure, two RAN gateways can be connected together through a direct link. This link allows radio frames containing data and RAN control protocol to flow between two RANs. As a result, two RANs can perform soft handoff between them, increasing the quality and reliability of the connection when a user moves between coverage areas. A RAN gateway and its collection of base stations can only cover a limited geographic area, so RAN interconnection is very important in cellular networks for maintaining good connection quality over large geographic areas. 4.0 Applicability of IP Mobility to Soft Handoff Most of the proposals for IP mobility in the RAN assume the following: 1) An end-to-end IP routing model for routing through the RAN. 2) A one-to-one mapping between the mobile terminal and the base station with which it is in contact. 3) The IP packets coming from the mobile terminal are transported directly on L2 in the RAN. As the above discussion has attempted to show, the extremely tight real time constraints on traffic in the RAN require that RAN traffic be highly processed as radio frames for efficient delivery into and from the radio medium by the base stations. This precludes routing IP packets from the mobile directly over the RAN. Furthermore, because there are multiple octet streams flowing over the RAN that correspond to one logical octet stream going to and from the mobile terminal, there is no one-to-one mapping between the mobile terminal and a base station. Taking mobile IP as an example, using mobile IP in the RAN would require that a mobile IP foreign agent (FA) be present at each base Kempf, McCann, Roberts expires October 2000 [Page 8] INTERNET DRAFT April 2000 station. However, because the mobile terminal can be in contact with up to 6 base stations at once, there is no unique care-of address for the mobile (unless the mobile uses a co-located care-of address). Therefore, the home agent (HA) would need to forward packets to multiple FAs. Furthermore, on the reverse leg, a frame selector is still necessary to generate a single packet for the corresponding node. In effect, the RAN controller is an application level transport and mobility mechanism specialized to the CDMA radio medium. It is therefore not a good candidate for replacing with network level mobility mechanisms. Because of the hard real time constraints involved in soft handoff, the RAN controller's soft handoff function is also not a good candidate for replacing with more general application level mechanisms, such as SIP [4]. 5.0 Applicability of IP Mobility to Hard Handoff Note that the above considerations do not apply to hard handoff, which occurs outside of the RAN. When a mobile terminal moves between two RANs that are not interconnected, the RAN controller defers handoff to the core network. Some mechanism is necessary in the core network to move the mobile terminal's point of attachement at the network level. IP mobility solutions for fast handoff are applicable here. Proposals such as [6] that apply after frame selection do not involve soft handoff and therefore are appropriate for implementing fast, hard handoff. 6.0 Future Prospects for IP Mobility in the CDMA RAN What would it take to enable IP mobility in the RAN? The question is worth examining because the end-to-end model of networking which would be required to make IP mobility work in the RAN has attractions from the point of view of simplicity of network management and transparency. Certainly, routing the mobile's packets directly in the RAN would be a major contributor. For that to happen, IP over the air interface would be necessary. The major impediment to IP over the air is currently header size, but new work in header compression may eliminate this objection. Given that a spectrally efficient representation of IP on the radio medium is possible, IP packets can be sent out over the air by the mobile terminal, and the base stations can handle the packets precisely as they currently do with the specialized radio frames. The result would be that IP packets from the radio would appear directly on L2 in the RAN. Kempf, McCann, Roberts expires October 2000 [Page 9] INTERNET DRAFT April 2000 However, there is still a problem with macrodiversity. On the forward leg, the routing from a single source at the RAN gateway to multiple base stations looks like multicast, but the real time constraints are extremely tight. A multicast routing algorithm with routing tree modifications that converge in real time might contribute to solving the problem. On the other hand, the reverse leg traffic would still need to be combined in the wired network behind the base stations. While the prospects for moving IP into the RAN are good, it seems unlikely that IP mobility will play any role in replacing CDMA soft handoff in the immediate future. CDMA soft handoff appears to be a very specialized form of transport-level or link layer mobility, and therefore not a good candidate for replacement by more general network or application level mechanisms. In addition, even if IP is used for transport in the RAN, if voice over IP is to completely replace the current radio voice protocols, voice packets may need to be processed at the RAN gateway for maximum efficiency and robustness over the radio medium. 7.0 Summary Most proposals for IP mobility require a one-to-one mapping between the mobile terminal and a base station with which it is in contact, and assume end-to-end connectivity and consequently routing in the radio access network based on the mobile's IP address. In CDMA networks, macrodiversity and the need for extremely low delay and jitter invalidate these assumptions. Consequently, IP mobility solutions are not applicable to CDMA soft handoff. These considerations do not, however, apply to hard handoff which occurs in the core network after frame selection. 8.0 References [1] Perkins, C. (ed.), IP Mobility Support for IPv4, revised, draft- ietf-mobileip-rfc2002-bis.txt (work in progress), January, 2000. [2] Vakil, Faramak, et. al., Host Mobility Management Protocol: Extending SIP to 3G-IP Networks, draft-itsumo-hmmp-00.txt (work in progress), October, 1999. [3] E. Wedlund and H. Schulzrinne. Mobility Support Using SIP. Second ACM/IEEE International Conference on Wireless and Mobile Multimedia (WoWMoM'99). Seattle, Washington. Aug. 1999. [4] O'Neill, A. and Corson, S., Edge Mobility Architecture, draft- oneill-ema-00.txt (work in progress), October, 1999. [5] Campbell, A., et. al., Cellular IP, draft-ietf-mobileip- Kempf, McCann, Roberts expires October 2000 [Page 10] INTERNET DRAFT April 2000 cellularip-00.txt, January, 2000. [6] Kempf, J. and Calhoun, P., Foreign Agent Assisted Hand-off, draft-calhoun-mobileip-proactive-fa-00.txt (work in progress), January, 2000. [7] Ramjee, R., et. al., IP micro-mobility support using HAWAII, Internet Draft (work in progress), June 1999. 9.0 Authors' Addresses Questions about this memo can be directed to: James Kempf Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 901 San Antonio Rd., UMPK15-214 Palo Alto, CA, 94303 USA Phone: +1 650 786 5890 Fax: +1 650 786 6445 E-Mail: james.kempf@sun.com Peter McCann Bell Laboratories 263 Shuman Boulevard Room 2Z-305 P.O. Box 3050 Naperville, IL, 60566 USA Phone: +1 630 713 9359 Fax: +1 630 713 4982 E-Mail: mccap@research.bell-labs.com Philip Roberts Motorola, Inc. 1501 W. Shure Dr. Arlington Heights, IL, 60015 Phone: +1 847 632 3148 E-Mail: qa3445@email.mot.com 9.0 Full Copyright Statement Kempf, McCann, Roberts expires October 2000 [Page 11] INTERNET DRAFT April 2000 Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Kempf, McCann, Roberts expires October 2000 [Page 12] --Sounder_of_Swine_044_000-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 3 11:24:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04256 for ; Wed, 3 May 2000 11:24:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1BACF4435D; Wed, 3 May 2000 11:19:27 -0400 (EDT) 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 7D2614435C for ; Wed, 3 May 2000 11:19:24 -0400 (EDT) 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 LAA06113; Wed, 3 May 2000 11:24:45 -0400 (EDT) Message-ID: <391044BD.849171BC@cs.columbia.edu> Date: Wed, 03 May 2000 11:24:45 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: iana@iana.org Cc: sip@lists.bell-labs.com, "Mathieu Gervais (LMC)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP URL scheme Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dear IANA: ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes is missing the sip: URL scheme defined in RFC 2543, a Proposed Standard. What is the process of having it added to the list? Thank you. 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 Wed May 3 12:53:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06057 for ; Wed, 3 May 2000 12:53:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23B044435E; Wed, 3 May 2000 12:48:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from true1.netrue.com (true1.netrue.com [207.104.210.201]) by lists.bell-labs.com (Postfix) with ESMTP id 302F84435D for ; Wed, 3 May 2000 12:48:01 -0400 (EDT) Received: from twang ([207.104.210.235]) by true1.netrue.com (Post.Office MTA v3.1 release PO205e ID# 0-34118U100L2S100) with SMTP id AAA74 for ; Wed, 3 May 2000 09:45:52 -0700 From: "Tricia Wang" To: "sip" Date: Wed, 3 May 2000 09:55:05 -0700 Message-ID: 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: <753C243100F8D211B15C0800060D9D6EC3C2D8@siepor43.net.siemens.pt> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [SIP] Accounting and Biling in SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello, Can anyone help me understand how SIP deal with accounting, billing and CDR (call detail record). My understanding is that, proxy server or redirect server will save a log file each time a call terminates. And we can use the log files save to actually generates CDR. Is this correct? Thanks Tricia _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 3 12:59:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06355 for ; Wed, 3 May 2000 12:59:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB95644368; Wed, 3 May 2000 12:54:10 -0400 (EDT) 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 400874435E for ; Wed, 3 May 2000 12:54:08 -0400 (EDT) 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 MAA12866; Wed, 3 May 2000 12:59:30 -0400 (EDT) Message-ID: <39105AF2.830E528E@cs.columbia.edu> Date: Wed, 03 May 2000 12:59:30 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tricia Wang Cc: sip Subject: Re: [SIP] Accounting and Biling in SIP References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit See the SIP FAQ at http://www.cs.columbia.edu/sip/ Tricia Wang wrote: > > Hello, > Can anyone help me understand how SIP deal with accounting, billing and > CDR (call detail record). > My understanding is that, proxy server or redirect server will save a log > file each time a call terminates. > And we can use the log files save to actually generates CDR. Is this > correct? > -- 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 May 3 13:48:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07401 for ; Wed, 3 May 2000 13:48:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4457344351; Wed, 3 May 2000 13:42:42 -0400 (EDT) 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 B53D944340 for ; Wed, 3 May 2000 13:42:39 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed May 3 13:46:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 75CFC44344; Wed, 3 May 2000 13:33:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 4D2B044341 for ; Wed, 3 May 2000 13:33:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1578E52C4; Wed, 3 May 2000 13:33:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 4F30352BB for ; Wed, 3 May 2000 13:33:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed May 3 13:32:38 EDT 2000 Received: from imr1.ericy.com ([208.237.135.240]) by dusty; Wed May 3 13:32:37 EDT 2000 Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id MAA04256; Wed, 3 May 2000 12:32:06 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id MAA26201; Wed, 3 May 2000 12:31:56 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA01125; Wed, 3 May 2000 12:32:04 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id MAA18556; Wed, 3 May 2000 12:32:04 -0500 (CDT) Date: Wed, 3 May 2000 12:32:04 -0500 (CDT) Message-Id: <200005031732.MAA18556@b04a45.exu.ericsson.se> To: jdrosen@dynamicsoft.com Subject: Re: [SIP] Second try : Questions about REGISTER Cc: sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > I'm not sure I see what is gained by adding a user portion. What is the > semantic of having a user portion in the request URI? This still doesn't > change how a proxy looks up registrations when an INVITE request is > received (still based on request URI), which is what Dean is asking for. > But it could open the possibility of changing how the REGISTER request gets routed/handled based on the user portion of the Request-URI. (The routing I'm speaking of is outside the realm of SIP, but shouldn't be precluded by the SIP protocol). In other words, many SIP clients will be configurable as to where to send it's periodic REGISTER messages. Allowing this configuration to be a full SIP URL including a user should make no difference to the client, but may make a difference to the registrar. Probably 90% of the registrars that get deployed won't use the user portion, but there's no reason why those remaining 10% couldn't. Treating the URL as opaque (from the client perspective) is a useful service primitive. > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 3 13:53:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07481 for ; Wed, 3 May 2000 13:53:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6DDE244369; Wed, 3 May 2000 13:47:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by lists.bell-labs.com (Postfix) with ESMTP id E451144365 for ; Wed, 3 May 2000 13:47:48 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id NAA26327; Wed, 3 May 2000 13:52:57 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568D4.006237F7 ; Wed, 3 May 2000 13:52:48 -0400 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: James Kempf Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, sip@lists.bell-labs.com Message-ID: <852568D4.00623794.00@notes949.cc.telcordia.com> Date: Wed, 3 May 2000 13:52:15 -0400 Subject: Re: [SIP] Applicability of IP Mobility to CDMA Soft Handoff 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com HI James & co, I have few questions after my first reading of the draft Page 7: When you talk about RAN-RAN interconnection (closley coupled way), what is your assumption? Does each neighboring RAN (RAN-GW) belong to a different IP subnet? or these RAN-GWs belong to the same subnet but are just distributed along. Page 6: Client listening to multiple base stations (3 or 6) at the same time: Do you assume multiple interfaces on the client or just one? In cases where the neighboring BSs for a mobile client are part of RANs belonging to different subnets ( and controlled by different RAN-GW), how does the RAN-GWs interact with each other to take care of soft-handoff, probably some sort of IP-mobility solution like IP multicast can be helpful here. Thanks Ashutosh _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 3 15:34:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09706 for ; Wed, 3 May 2000 15:34:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 27C9044340; Wed, 3 May 2000 15:28:41 -0400 (EDT) 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 6DC7B4433E for ; Wed, 3 May 2000 15:28:38 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 15:32:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 17DBF44344; Wed, 3 May 2000 15:19:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E4E7244341 for ; Wed, 3 May 2000 15:19:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B0E0752BB; Wed, 3 May 2000 15:19:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C4FDF52B6 for ; Wed, 3 May 2000 15:19:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 15:17:08 EDT 2000 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Wed May 3 15:17:08 EDT 2000 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 MAA02090; Wed, 3 May 2000 12:17:12 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAA27878; Wed, 3 May 2000 12:14:30 -0700 (PDT) Message-Id: <4.2.0.58.20000503121027.0331b9c0@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 03 May 2000 12:13:39 -0700 To: Henning Schulzrinne From: Rohan Mahy Subject: Re: [SIP] Problem with the syntax of URI extension parameters Cc: Igor Slepchin , Jonathan Lennox , sip@lists.research.bell-labs.com In-Reply-To: <390F9E8E.10FAEAB1@cs.columbia.edu> References: <200005022203.SAA34631@conrail.cs.columbia.edu> <390F9700.F3FA43D8@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com So in which contexts do i need to escape the <"> in this parameter? ?Request-Contact=*;mobility="mobile" (obviously when the sip:URL is encoded in HTML) thanks, -rohan At 08:35 PM 5/2/00 , Henning Schulzrinne wrote: >Igor Slepchin wrote: > > > > You would probably want to exclude "?" and "," from param-reserved: "?" > > - to eliminate the ambiguity with "?" that separates parameters from > >Done. > > > headers, "," - because URLs are allowed in certain headers and allowing > > commas in SIP URLs will make parsing those headers sometime impossible. > >As far as I know, all headers where URLs are allowed mandate the use of ><> for URLs with commas or other "bad" characters. Any we missed? >(Probably still a good idea to make it reserved; the pain is small >compared to the confusion avoided.) > > > > > Another observation: to be as backward compatible as possible the > > characters allowed in param-reserved should be a subset of those allowed > > in token. The intersection of reserved from RFC2396 and token from > > RFC2543 leaves us with the following > > > > param-reserved = "+" > >Anybody object to this most restrictive coding? The only slight problem >with being restrictive is that it makes hand-coding HTML pages with SIP >URLs more painful. On the other hand, we haven't really defined any >parameters likely to see $ or @. However, removing : doesn't work well, >since we allow it in IPv6 numerical addresses in the maddr parameter. >Would seem strange to force escaping here. > > > > > Also, note that unreserved in RFC2396 allows "(" and ")", while token > > does not. On the other hand, I don't think that many implementations > > will get broken if those extra characters are allowed. > > > > >-- >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 May 3 15:54:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09991 for ; Wed, 3 May 2000 15:54:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3497B44340; Wed, 3 May 2000 15:48:41 -0400 (EDT) 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 B113E4433E for ; Wed, 3 May 2000 15:48:38 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 15:52:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 22F9E44344; Wed, 3 May 2000 15:39:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E940E44341 for ; Wed, 3 May 2000 15:39:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 94BB352BB; Wed, 3 May 2000 15:39:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id B65F352AB for ; Wed, 3 May 2000 15:39:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed May 3 15:38:37 EDT 2000 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by dusty; Wed May 3 15:38:35 EDT 2000 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FU000I9I1879M@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 3 May 2000 19:38:32 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FU000K0117L6Z@dgismtp03.wcomnet.com>; Wed, 03 May 2000 19:38:11 +0000 (GMT) Received: from omzmta02.mcit.com ([166.37.214.8]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FU000J6B178K1@dgismtp03.wcomnet.com>; Wed, 03 May 2000 19:37:57 +0000 (GMT) Received: from dwillispc8 ([166.35.248.87]) by omzmta02.mcit.com (InterMail v03.02.07.05 118-131) with SMTP id <20000503193816.XYGJ18085@dwillispc8>; Wed, 03 May 2000 19:38:16 +0000 Date: Wed, 03 May 2000 14:37:41 -0500 From: Dean Willis Subject: RE: [SIP] Second try : Questions about REGISTER In-reply-to: <200005031732.MAA18556@b04a45.exu.ericsson.se> To: Sean Olson , jdrosen@dynamicsoft.com Cc: sip@lists.research.bell-labs.com Message-id: <002201bfb537$0bf1fbe0$57f823a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan said: > > I'm not sure I see what is gained by adding a user portion. What is the > > semantic of having a user portion in the request URI? This still doesn't > > change how a proxy looks up registrations when an INVITE request is > > received (still based on request URI), which is what Dean is asking for. > > and Sean said: > But it could open the possibility of changing how the REGISTER > request gets routed/handled > based on the user portion of the Request-URI. (The routing I'm > speaking of is outside > the realm of SIP, but shouldn't be precluded by the SIP > protocol). In other words, > many SIP clients will be configurable as to where to send it's > periodic REGISTER messages. > Allowing this configuration to be a full SIP URL including a user > should make no > difference to the client, but may make a difference to the > registrar. Probably 90% of > the registrars that get deployed won't use the user portion, but > there's no reason > why those remaining 10% couldn't. Treating the URL as opaque > (from the client perspective) > is a useful service primitive. Does an INVITE have to be delivered only to the node indicated in the right-hand-side of the request-URI? No, because we require transitivity support in a proxy -- that is, we can ask a proxy to resolve something that we know is not local to that proxy. That's what makes it a proxy, from my point of view. Similarly, the To: and request-URI can differ due to request transformations that have occurred in the proxy chain. This is different from REGISTER. From 4.2.6 "The Request-URI names the destination of the registration request, i.e., the domain of the registrar". Why? So a register can be proxied -- that is, a proxy/registrar can decide whether the REGISTER was meant for it, and if not resolve the next hop towards a registrar using the request-URI. Or so that a multidomain registrar can determine which domain the registration should be valid in. I argue more granularity is needed. So, what would be the semantic of (if it were allowed) REGISTER dwillis@softarmor.com To: dean.willis@wcom.com Contact:@63.64.250.84 What I want this to mean is "Within the registrar "softarmor.com" there is an identity "dwillis". Calls directed to this identity which have a "To:" value of dean.willis@wcom.com should be diverted to @63.64.250.85". The registration being changed is the one for the identity "dwillis@softarmor.com", NOT the identity "dean.willis@wcom.com". This would further imply: 1) Mimicing today's behavior would require moving to To: value to the request-URI. That is: REGISTER dwillis@softarmor.com Contact:@63.64.250.84 would, in the absence of other registrations and rules, forward any INVITE with a request-URI of dwillis@softarmor.com to the UAS @63.64.250.84 2) Traditional behavior would occur with a To: which matches the request-URI iff the proxy/registrar does not offer To: field matching. The other question is, what would the implications be for authentication? Essentially, we would be saying that the registration target is the body of the request-URI, not the body of the To: I find this far more consistent with the semantics of INVITE and OPTIONS than the current approach is. -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 3 18:22:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12119 for ; Wed, 3 May 2000 18:22:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 101CC4434B; Wed, 3 May 2000 18:16:38 -0400 (EDT) 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 3CAC34433E for ; Wed, 3 May 2000 18:16:36 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 18:20:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2044D44344; Wed, 3 May 2000 18:07:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id ED0BC44341 for ; Wed, 3 May 2000 18:07:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A457052BB; Wed, 3 May 2000 18:07:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C09D952AB for ; Wed, 3 May 2000 18:07:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 18:05:55 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 3 18:05:55 EDT 2000 Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA02725; Wed, 3 May 2000 18:06:58 -0400 (EDT) Message-ID: <3910A531.9A908CD1@dynamicsoft.com> Date: Wed, 03 May 2000 18:16:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ge Yu Cc: Shail Bhatnagar , "'Alexandru Gavrilescu'" , SIP IETF Subject: Re: [SIP] Second try : Questions about REGISTER References: <30A14FB41CC5D311854D00508B5EEF0201ED5563@exs23.ex.nus.edu.sg> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ge Yu wrote: > > Hi, friends, > > As I know through 16.1 of RFC 2543, the registration process is as follows: > > 1. Watson firstly sends the REGISTER request to the server at bell-tel.com, > with Contact: Watson@example.com. That is, he hasn't contacted with the > server at example.com ahead of REGISTER. > So what happens if another Watson@example.com has been registered in > example.com domain? Watson wouldn't send the registration with Contact: watson@example.com unless he was sure he owned that name at example.com. The assumption, stated in 16.1, is that watson has visiting rights at example.com, and so he knows that watson@example.com is his own address. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 3 18:30:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12256 for ; Wed, 3 May 2000 18:30:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8CD844365; Wed, 3 May 2000 18:24:39 -0400 (EDT) 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 550864434B for ; Wed, 3 May 2000 18:24:37 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 18:28:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7F1CE44345; Wed, 3 May 2000 18:15:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 5146744341 for ; Wed, 3 May 2000 18:15:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 16D1252BB; Wed, 3 May 2000 18:15:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F3CEF52AB for ; Wed, 3 May 2000 18:15:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 18:13:42 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 3 18:13:42 EDT 2000 Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA02745; Wed, 3 May 2000 18:14:57 -0400 (EDT) Message-ID: <3910A710.1C3EC3FD@dynamicsoft.com> Date: Wed, 03 May 2000 18:24:16 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: Sean Olson , sip@lists.research.bell-labs.com Subject: Re: [SIP] Second try : Questions about REGISTER References: <002201bfb537$0bf1fbe0$57f823a6@mcit.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Jonathan said: > > > I'm not sure I see what is gained by adding a user portion. What is the > > > semantic of having a user portion in the request URI? This still doesn't > > > change how a proxy looks up registrations when an INVITE request is > > > received (still based on request URI), which is what Dean is asking for. > > > > > and Sean said: > > But it could open the possibility of changing how the REGISTER > > request gets routed/handled > > based on the user portion of the Request-URI. (The routing I'm > > speaking of is outside > > the realm of SIP, but shouldn't be precluded by the SIP > > protocol). In other words, > > many SIP clients will be configurable as to where to send it's > > periodic REGISTER messages. > > Allowing this configuration to be a full SIP URL including a user > > should make no > > difference to the client, but may make a difference to the > > registrar. Probably 90% of > > the registrars that get deployed won't use the user portion, but > > there's no reason > > why those remaining 10% couldn't. Treating the URL as opaque > > (from the client perspective) > > is a useful service primitive. > So, what would be the semantic of (if it were allowed) > REGISTER dwillis@softarmor.com > To: dean.willis@wcom.com > Contact:@63.64.250.84 > > What I want this to mean is "Within the registrar "softarmor.com" there is > an identity "dwillis". Calls directed to this identity which have a "To:" > value of dean.willis@wcom.com should be diverted to @63.64.250.85". The > registration being changed is the one for the identity > "dwillis@softarmor.com", NOT the identity "dean.willis@wcom.com". This is not the semantics of REGISTER as they are today; I would be unfortable changing the semantics like this because a user portion has been added to the REGISTER request URI. A proxy would have very different rules for routing depending on how the registration looked. If you want non-standard routing, have the clients or administrators upload CPL or CGI scripts to do these things. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 4 03:21:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00444 for ; Thu, 4 May 2000 03:21:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7072244340; Thu, 4 May 2000 03:15:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id 849684433E for ; Thu, 4 May 2000 03:15:18 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id JAA29366 for ; Thu, 4 May 2000 09:15:40 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA28906 for ; Thu, 4 May 2000 09:20:37 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id JAA28909 for ; Thu, 4 May 2000 09:20:34 +0200 (MET DST) Received: from young.dinsunnet (young [188.9.34.36]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id JAA06382 for ; Thu, 4 May 2000 09:17:10 +0200 (MET DST) Received: from ms.alcatel.fr by young.dinsunnet (8.9.1b+Sun/SMI-SVR4) id JAA18634; Thu, 4 May 2000 09:17:11 +0200 (MET DST) Message-ID: <391123F7.CAB9828C@ms.alcatel.fr> Date: Thu, 04 May 2000 09:17:11 +0200 From: Francois-Xavier Guitton X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: SIP Subject: [SIP] questions for clarification on SDP negociation Content-Type: multipart/alternative; boundary="------------E1B13077538FF7B5006113C7" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------E1B13077538FF7B5006113C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, When I read RFC2543, Annex B - Usage of SDP p 136, I am a little bit confused. Could you answer the following questions : 1/ RFC 2327 (SDP) defines 3 attributes a=recvonly, a=sendrcv and a=sendonly. But, in SIP, do we consider a media is by default bi-directional ? The example p 137 seems to tell that, but does someone know where that is written ? 2/ Is it possible for a user agent to add new media in the SDP part of the answer to a received INVITE? For example A INVITE B with media: m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Does it make sense B answers 200 OK with: m=audio 4910 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 5300 RTP/AVP 32 a=rtpmap:32 MPV/90000 The underlying question being: What type of media are listed in the SDP part : the media supported by the User Agent ? or the media the Human user wishes to use in the SIP session ? In that case, A could wish an audio session but B would prefer an audio-video session. If we suppose A supports also video capabilities, what will answer A : ACK with audio + video media description ??? Or is a new INVITE from A to B required ? 3/ Where is defined the list of all the types of rtpmap (e.g.: PCMU, H261, MPV ...) supported by SIP in the SDP part ? Regards, Fxg PS: What is the status of draft-ietf-sip-rfc2543bis ? Is it now the reference instead of RFC 2543 ? ./. -- Francois-Xavier Guitton (SWD/ULC) mailto:Francois-Xavier.Guitton@ms.alcatel.fr Tel: +33 (0)1 69 63 47 52 Fax: +33 (0)1 69 63 17 89 --------------E1B13077538FF7B5006113C7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit All,

When I read RFC2543, Annex B - Usage of SDP p 136, I am a little bit confused. Could you answer the following questions :

1/ RFC 2327 (SDP) defines 3 attributes a=recvonly, a=sendrcv and a=sendonly. But, in SIP, do we consider a media is by default bi-directional ? The example p 137 seems to tell that, but does someone know where that is written ?

2/ Is it possible for a user agent to add new media in the SDP part of the answer to a received INVITE?

For example A INVITE B with  media:
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Does it make sense B answers 200 OK with:
m=audio 4910 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 5300 RTP/AVP 32
a=rtpmap:32 MPV/90000

The underlying question being: What type of media are listed in the SDP part : the media supported by the User Agent ? or the media the Human user wishes to use in the SIP session ? In that case, A could wish an audio session but B would prefer an audio-video session. If we suppose A supports also video capabilities, what will answer A : ACK with audio + video media description ??? Or is a new INVITE from A to B required ?

3/ Where is defined the list of all the types of rtpmap (e.g.: PCMU, H261, MPV ...) supported by SIP in the SDP part ?

Regards,

Fxg

PS: What is the status of draft-ietf-sip-rfc2543bis ? Is it now the reference instead of RFC 2543 ?

./. 

-- 
Francois-Xavier Guitton (SWD/ULC)
mailto:Francois-Xavier.Guitton@ms.alcatel.fr      
Tel: +33 (0)1 69 63 47 52                    
Fax: +33 (0)1 69 63 17 89
  --------------E1B13077538FF7B5006113C7-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 4 04:01:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00849 for ; Thu, 4 May 2000 04:01:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D071D44340; Thu, 4 May 2000 03:55:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from backrosh.inter.net.il (backrosh.inter.net.il [192.116.202.45]) by lists.bell-labs.com (Postfix) with ESMTP id D95B04433E for ; Thu, 4 May 2000 03:55:21 -0400 (EDT) Received: from 192.116.213.130 ([192.116.213.130]) by backrosh.inter.net.il (8.9.3/8.9.3) with SMTP id LAA29481 for ; Thu, 4 May 2000 11:00:47 +0300 (IDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by 192.116.213.130 ; Thu, 04 May 2000 10:56:53 -0700 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 4 May 2000 10:59:49 +0300 Message-ID: From: Itamar Gilad To: "'Francois-Xavier.Guitton@ms.alcatel.fr'" Cc: "'SIP List'" Subject: FW: [SIP] questions for clarification on SDP negociation Date: Thu, 4 May 2000 10:59:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB59E.B868FF40" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFB59E.B868FF40 Content-Type: text/plain; charset="iso-8859-1" Francois, see comments below marked [Itamar Gilad]. Itamar -----Original Message----- From: Francois-Xavier Guitton [mailto:Francois-Xavier.Guitton@ms.alcatel.fr] Sent: Thu, May 04, 2000 9:17 AM To: SIP Subject: [SIP] questions for clarification on SDP negociation All, When I read RFC2543, Annex B - Usage of SDP p 136, I am a little bit confused. Could you answer the following questions : 1/ RFC 2327 (SDP) defines 3 attributes a=recvonly, a=sendrcv and a=sendonly. But, in SIP, do we consider a media is by default bi-directional ? The example p 137 seems to tell that, but does someone know where that is written ? [Itamar Gilad] I'm not sure where it's written, but the general idea as I understand it is that by default the sender of the INVITE informs of the media it is willing to send AND receive. If you wish to specify asymmetric send/receive capabilities you need to set up two m= lines, one with a=sendonly and one with a=recvonly. 2/ Is it possible for a user agent to add new media in the SDP part of the answer to a received INVITE? For example A INVITE B with media: m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Does it make sense B answers 200 OK with: m=audio 4910 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 5300 RTP/AVP 32 a=rtpmap:32 MPV/90000 The underlying question being: What type of media are listed in the SDP part : the media supported by the User Agent ? or the media the Human user wishes to use in the SIP session ? In that case, A could wish an audio session but B would prefer an audio-video session. If we suppose A supports also video capabilities, what will answer A : ACK with audio + video media description ??? Or is a new INVITE from A to B required ? [Itamar Gilad] B can't add new media which A did not specify in the original INVITE. It can either accept a subset or whole of the the media streams and codecs suggested by A or decline the invitation. Once a session has been established either side can attempt adding new media streams by sending a re-INVITE with an appropriate SDP body (see B.5 in RFC2543-bis). 3/ Where is defined the list of all the types of rtpmap (e.g.: PCMU, H261, MPV ...) supported by SIP in the SDP part ? [Itamar Gilad] As far as I know SIP does not set any limit on the types of media describable in the SDP body. See also RFC1889 and RFC1890. Regards, Fxg PS: What is the status of draft-ietf-sip-rfc2543bis ? Is it now the reference instead of RFC 2543 ? ./. -- Francois-Xavier Guitton (SWD/ULC) mailto:Francois-Xavier.Guitton@ms.alcatel.fr Tel: +33 (0)1 69 63 47 52 Fax: +33 (0)1 69 63 17 89 ------_=_NextPart_001_01BFB59E.B868FF40 Content-Type: text/html; charset="iso-8859-1"

Francois, see comments below marked [Itamar Gilad].
 
  Itamar
-----Original Message-----
From: Francois-Xavier Guitton [mailto:Francois-Xavier.Guitton@ms.alcatel.fr]
Sent: Thu, May 04, 2000 9:17 AM
To: SIP
Subject: [SIP] questions for clarification on SDP negociation

All,

When I read RFC2543, Annex B - Usage of SDP p 136, I am a little bit confused. Could you answer the following questions :

1/ RFC 2327 (SDP) defines 3 attributes a=recvonly, a=sendrcv and a=sendonly. But, in SIP, do we consider a media is by default bi-directional ? The example p 137 seems to tell that, but does someone know where that is written ?

[Itamar Gilad] I'm not sure where it's written, but the general idea as I understand it is that by default the sender of the INVITE informs of the media it is willing to send AND receive.  If you wish to specify asymmetric send/receive capabilities you need to set up two m= lines, one with a=sendonly and one with a=recvonly.


2/ Is it possible for a user agent to add new media in the SDP part of the answer to a received INVITE?

For example A INVITE B with  media:
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Does it make sense B answers 200 OK with:
m=audio 4910 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 5300 RTP/AVP 32
a=rtpmap:32 MPV/90000

The underlying question being: What type of media are listed in the SDP part : the media supported by the User Agent ? or the media the Human user wishes to use in the SIP session ? In that case, A could wish an audio session but B would prefer an audio-video session. If we suppose A supports also video capabilities, what will answer A : ACK with audio + video media description ??? Or is a new INVITE from A to B required ?

[Itamar Gilad] B can't add new media which A did not specify in the original INVITE. It can either accept a subset or whole of the the media streams and codecs suggested by A or decline the invitation. Once a session has been established either side can attempt adding new media streams by sending a re-INVITE with an appropriate SDP body (see B.5 in RFC2543-bis). 

3/ Where is defined the list of all the types of rtpmap (e.g.: PCMU, H261, MPV ...) supported by SIP in the SDP part ?

[Itamar Gilad] As far as I know SIP does not set any limit on the types of media describable in the SDP body.  See also RFC1889 and RFC1890.  

Regards,

Fxg

PS: What is the status of draft-ietf-sip-rfc2543bis ? Is it now the reference instead of RFC 2543 ?

./. 

-- 
Francois-Xavier Guitton (SWD/ULC)
mailto:Francois-Xavier.Guitton@ms.alcatel.fr      
Tel: +33 (0)1 69 63 47 52                    
Fax: +33 (0)1 69 63 17 89
 
------_=_NextPart_001_01BFB59E.B868FF40-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 4 06:36:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01941 for ; Thu, 4 May 2000 06:36:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DCFCF44370; Thu, 4 May 2000 06:30:42 -0400 (EDT) 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 4D3DB4433E for ; Thu, 4 May 2000 06:30:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01907; Thu, 4 May 2000 06:36:07 -0400 (EDT) Message-Id: <200005041036.GAA01907@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com, mobile-ip@standards.nortelnetworks.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 04 May 2000 06:36:07 -0400 Subject: [SIP] I-D ACTION:draft-kempf-cdma-appl-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft Handoff Author(s) : J. Kempf, P. McCann, P. Roberts Filename : draft-kempf-cdma-appl-00.txt Pages : 12 Date : 03-May-00 Recently, there have been a variety of proposals submitted to the Mobile IP Working Group and to other IETF working groups for IP mobility solutions that seek to enhance or replace mobile IP. These proposals, often characterized as micromobility or fast handoff, are addressed primarily at the perceived need of multimedia sessions such as video or voice over IP for faster handoff between radio base stations, and are primarily directed at real time multimedia traffic in 3rd generation cellular access networks. In this paper, we discuss the design of CDMA radio access networks (RANs) and the applicability of IP mobility to soft handoff in a CDMA RAN. We attempt to show that given current IP routing algorithms and the constraints on a CDMA RAN, IP mobility solutions have little, if any, role to play in handoff within the RAN. In contrast, an IP mobility solution is likely to play a big role in fast handoff between RANs, also called hard handoff. While future developments in IP networking may change this situation, IP mobility in CDMA networks currently seems to apply only when the mobile node roams between RANs rather than between base stations within a RAN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kempf-cdma-appl-00.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-kempf-cdma-appl-00.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-kempf-cdma-appl-00.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: <20000503111149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kempf-cdma-appl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kempf-cdma-appl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000503111149.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 4 11:23:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08184 for ; Thu, 4 May 2000 11:23:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0331C44365; Thu, 4 May 2000 11:17:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id BBB684433E for ; Thu, 4 May 2000 11:17:13 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28565; Thu, 4 May 2000 09:22:34 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA04284; Thu, 4 May 2000 08:19:24 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA06402; Thu, 4 May 2000 08:19:23 -0700 (PDT) Message-Id: <200005041519.IAA06402@nasnfs.eng.sun.com> Date: Thu, 4 May 2000 08:22:07 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [SIP] Applicability of IP Mobility to CDMA Soft Handoff To: James.Kempf@eng.sun.com, adutta@telcordia.com Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Pm1qnwKqLkBHUQeLL2QIqA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >HI James & co, I have few questions after my first reading of the draft >Page 7: > When you talk about RAN-RAN interconnection (closley coupled way), >what is your assumption? Does each neighboring RAN (RAN-GW) belong to a >different IP subnet? or these RAN-GWs belong to the same subnet but are just >distributed along. > Whether or not they belong to a different subnet is not important from the point of view of a moving terminal, since the terminal's IP packets are not routed through the RAN based on the terminal's IP address. The termimal's packets are processed into radio frames, in which the IP packets are encoded. If the RAN is IP based (it may not be and, in fact, in current 2G and 3G designs is not), then the links are typically point to point or at most one hop, due to the stringent timing constraints. The radio frames in an IP-based RAN would run on top of IP (maybe UDP) directly, and the terminal's IP packets would not be identifiable in the RAN as such, except by performing the same processing the terminal's CDMA hardware performs to decode the radio frames. >Page 6: > > Client listening to multiple base stations (3 or 6) at the same >time: Do you assume multiple interfaces on the client or just one? >In cases where the neighboring BSs for a mobile client are part of RANs >belonging to different subnets ( and controlled by different RAN-GW), how does >the RAN-GWs interact with each other to take care of soft-handoff, probably some >sort of IP-mobility solution like IP multicast can be helpful here. > The client has only one "interface" in the IP sense. A mobile CDMA phone uses a signal processing technique to combine the incoming signals to produce a single packet. This process proceeds at the physical layer, i.e. L1, and therefore the upper layers never see more than a single packet as was incoming to the frame selector/ distributor from the corresponding node. So the phone can have only a single IP address for the CDMA connection, even though at the physical layer there are multiple signals coming in with the same (modulo errors) octet stream. This characteristic is the single largest deterrent to using IP mobility in CDMA RANs. jak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 4 14:52:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13951 for ; Thu, 4 May 2000 14:52:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3233D44353; Thu, 4 May 2000 14:46:33 -0400 (EDT) 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 BCA494433E for ; Thu, 4 May 2000 14:46:30 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu May 4 14:50:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0FDFA44344; Thu, 4 May 2000 14:37:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id D791744341 for ; Thu, 4 May 2000 14:37:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 73A3E52BB; Thu, 4 May 2000 14:37:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7FA0652B6 for ; Thu, 4 May 2000 14:37:07 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 4 14:36:27 EDT 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Thu May 4 14:36:26 EDT 2000 Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id UAA21161 for ; Thu, 4 May 2000 20:36:25 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 4 May 2000 20:34:47 +0200 Received: from esealnt406-in.al.sw.ericsson.se ([153.88.251.29]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 04 May 2000 18:34:47 0000 (GMT) Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt406-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 4 May 2000 20:32:57 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Thu, 4 May 2000 20:36:22 +0200 Message-ID: <7F962CB50869D2118A510008C7A4D3C4020E87DD@edkchnt100.lmd.ericsson.se> From: "Hans-henrik Veisner (DXD)" To: sip@lists.research.bell-labs.com Subject: RE: [SIP] Content Lenght in responses Date: Thu, 4 May 2000 17:30:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 May 2000 18:32:57.0812 (UTC) FILETIME=[2B53B940:01BFB5F7] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi! What about the case where a UAC sends an INVITE and the UAS returns a 18x response and closes the connection to indicate the end of the message. Shouldn't the UAC interpret this as a 500 response as described in section 10.3 in the rfc2543bis draft? Hans-Henrik Veisner, ANS IP Convergence Ericsson Diax -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 3. maj 2000 06:33 To: Natarajan Kalpathy Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Content Lenght in responses Natarajan Kalpathy wrote: > > Why is the Content Length field not mandatory in cases of SIP responses ??. Wont > it simplify the message processing in case of TCP. The current rfc2543bis draft > says > > "If a response does not contain a Content-Length, the client assumes that it > encompasses the remainder > of the UDP packet or the data until the TCP connection is closed, as applicable. > " > > Please clarify .... I believe this is the result of legacy HTTP, where Content-Length is not mandatory in responses. I also believe this is because CGI scripts that generate dynamic content wouldn't know the Content Length ahead of time, so just sending data, and then closing the connection, was the easiest way to determine message length. I can certainly envision placing of dynamic content in SIP responses, so this may prove useful for us as well. Processing of responses without content length is pretty simple anyway. It just means an additional counter that counts actual bytes read from the response. When the connection closes, this value is your content length. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Thu May 4 16:47:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16736 for ; Thu, 4 May 2000 16:47:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5BDC44382; Thu, 4 May 2000 16:41:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ott-rd.ss8.ca (gw-ss8networks.storm.ca [209.87.234.122]) by lists.bell-labs.com (Postfix) with ESMTP id 56B584433E for ; Thu, 4 May 2000 16:41:38 -0400 (EDT) Received: from eberpc ([192.168.1.60]) by ott-rd.ss8.ca (8.9.3/8.9.3) with SMTP id QAA15928 for ; Thu, 4 May 2000 16:43:58 -0400 From: "Eber Mello" To: Date: Thu, 4 May 2000 16:49:12 -0700 Message-ID: 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.2314.1300 Subject: [SIP] Registrar providing location services Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Please, I have a few questions regarding the behavior of a SIP registrar providing location services vis-a-vis the action (proxy or redirect) present on the REGISTER message. 1) Should a proxy- *and* redirect capable SIP server chooses either to proxy or redirect a request based on the policy of the user addressed on the request, expressed by the user's REGISTER message? In other words, the location services provided by the registrar would return how - proxy or redirect, the user wants to be reached as well as a contact list? 2) Can a user register contacts that are actually well known SIP URLs of other users, as below? userA@domainX registers with action=PROXY, contact1=userB@domainY and contact2 = userC@domainZ. 3) Consider that userB and userC are also registered with the same registrar, as follows: userB@domainY registers with action=REDIRECT, contact=addressK@domainM and userC@domainZ registers with action=PROXY, contact=addressL@domainN => lets suppose that addressK@domainM and addressL@domainN are not locally registered When queried about the location of 'userA', should the location server recurse on the contacts of userA whenever it sees a SIP URL of a user also registered locally to it? 4) If the answer to the previous questions are YES, than the location server would return REDIRECT to addressK@domainM and PROXY to addressL@domainN - what is a scenario that the spec explicitly tries to avoid by enforcing that all contacts on a REGISTER must have the same 'action'. Thanks, Eber Mello SS8 Networks Canada. www.ss8networks.com phone: 613-5921418 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 4 18:03:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19422 for ; Thu, 4 May 2000 18:03:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C3EE4435C; Thu, 4 May 2000 17:57:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C7DDD4433E for ; Thu, 4 May 2000 17:57:37 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA07033; Thu, 4 May 2000 18:02:24 -0400 (EDT) Message-ID: <3911F289.9BF3D7D3@dynamicsoft.com> Date: Thu, 04 May 2000 17:58:33 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Eber Mello Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Registrar providing location services References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Eber Mello wrote: > > 1) Should a proxy- *and* redirect capable SIP server chooses > either to proxy or redirect a request based on the policy of the > user addressed on the request, expressed by the user's REGISTER > message? That's up to you. You can either honor user preferences or overwrite them. > 2) Can a user register contacts that are actually > well known SIP URLs of other users, as below? Sure. > > When queried about the location of 'userA', should the location server > recurse on the contacts of userA whenever it sees a SIP URL of a user > also registered locally to it? If domainM and domainN are served by the same proxy, it's a nice idea to do the recursive lookup. Nothing catastrophic happens if you don't - the proxy will just have to do the same lookup when it gets the request it just proxied to itself. > 4) If the answer to the previous questions are YES, than the location server > would return REDIRECT to addressK@domainM and PROXY to addressL@domainN - > what is > a scenario that the spec explicitly tries to avoid by enforcing that > all contacts on a REGISTER must have the same 'action'. I guess the question is about what to do when the recursed Contact has the action different from that in the first Contact. Well, that's up to the proxy: it can overwrite that action or, if this turns out to be the last Contact to try, it can overwrite the action from the first Contact. --- 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 Thu May 4 18:35:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19977 for ; Thu, 4 May 2000 18:35:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F11004438B; Thu, 4 May 2000 18:30:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from out.sssi.com (out.sssi.com [204.217.196.3]) by lists.bell-labs.com (Postfix) with ESMTP id BF5B04433E for ; Thu, 4 May 2000 18:30:02 -0400 (EDT) Received: by out.sssi.com; id RAA04611; Thu, 4 May 2000 17:36:45 -0500 (CDT) Received: from center.sssi.com(199.29.166.7) by out.sssi.com via smap (V4.2) id xma004605; Thu, 4 May 00 17:35:51 -0500 Received: (from clark@localhost) by center.sssi.com (8.6.12/8.6.9) id RAA22314 for sip@lists.bell-labs.com; Thu, 4 May 2000 17:23:24 -0500 Message-Id: <200005042223.RAA22314@center.sssi.com> To: sip@lists.bell-labs.com Date: Thu, 4 May 2000 17:23:24 -0500 (CDT) From: "G. Clark Brown" X-Mailer: ELM [version 2.4 PL23] Content-Type: text Subject: [SIP] Content-Language header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com draft-ietf-sip-rfc2543bis-00 refers to Content-Language header in 6.46, but it does not seem to formally define this header. Am I missing something? Clark _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 4 18:52:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20315 for ; Thu, 4 May 2000 18:52:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D940B4438C; Thu, 4 May 2000 18:46:45 -0400 (EDT) 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 591244437A for ; Thu, 4 May 2000 18:46:43 -0400 (EDT) Received: from cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA10863 for ; Thu, 4 May 2000 18:51:25 -0400 (EDT) Message-ID: <3911FEED.28717C81@cs.columbia.edu> Date: Thu, 04 May 2000 18:51:25 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------B64CD6FCAE296882F4450B90" Subject: [SIP] [Fwd: SIP URL scheme] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------B64CD6FCAE296882F4450B90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thus, whoever was dealing with the Mozilla folks can now point to the document http://www.isi.edu/in-notes/iana/assignments/url-schemes to prove legitimacy. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------------B64CD6FCAE296882F4450B90 Content-Type: message/rfc822 Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA18703 for ; Thu, 4 May 2000 18:18:57 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA08887 for ; Thu, 4 May 2000 18:18:55 -0400 (EDT) Received: from icann1 (icann1.isi.edu [128.9.160.34]) by boreas.isi.edu (8.8.7/8.8.6) with SMTP id PAA26863 for ; Thu, 4 May 2000 15:18:52 -0700 (PDT) Reply-To: From: "IANA" To: "'Henning Schulzrinne'" Subject: RE: SIP URL scheme Date: Thu, 4 May 2000 15:18:37 -0700 Message-ID: <000f01bfb616$b33fc5a0$22a00980@isi.edu> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <391044BD.849171BC@cs.columbia.edu> Content-Type: text/plain; charset="iso-8859-1" X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Dear Henning, Thank you for notifying the IANA. This has been added. Best regards, Michelle Schipper, Administrator IANA -----Original Message----- From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of Henning Schulzrinne Sent: Wednesday, May 03, 2000 8:25 AM To: iana@ISI.EDU Cc: sip@lists.bell-labs.com; Mathieu Gervais (LMC) Subject: SIP URL scheme Dear IANA: ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes is missing the sip: URL scheme defined in RFC 2543, a Proposed Standard. What is the process of having it added to the list? Thank you. Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------------B64CD6FCAE296882F4450B90-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 4 22:27:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24883 for ; Thu, 4 May 2000 22:27:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 577E24439A; Thu, 4 May 2000 22:20:29 -0400 (EDT) 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 E4CCE44398 for ; Thu, 4 May 2000 22:20:26 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 4 22:24:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8163344345; Thu, 4 May 2000 22:11:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 4E3A144341 for ; Thu, 4 May 2000 22:11:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1459C52BB; Thu, 4 May 2000 22:11:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 463CD52AB for ; Thu, 4 May 2000 22:11:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 4 22:10:04 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu May 4 22:10:03 EDT 2000 Received: from dynamicsoft.com (1Cust202.tnt2.freehold.nj.da.uu.net [63.17.114.202]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA07355; Thu, 4 May 2000 22:11:17 -0400 (EDT) Message-ID: <39122FF9.6429666F@dynamicsoft.com> Date: Thu, 04 May 2000 22:20:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hans-henrik Veisner (DXD)" Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Content Lenght in responses References: <7F962CB50869D2118A510008C7A4D3C4020E87DD@edkchnt100.lmd.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Hans-henrik Veisner (DXD)" wrote: > > Hi! > > What about the case where a UAC sends an INVITE and the UAS returns a 18x response and closes the connection to indicate the end of the message. Shouldn't the UAC interpret this as a 500 response as described in section 10.3 in the rfc2543bis draft? Yes. If you still have more responses to send after the 18x, include a Content-Length rather than closing the connection. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 4 22:55:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26202 for ; Thu, 4 May 2000 22:55:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 15EBD44395; Thu, 4 May 2000 22:49:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 774194433E for ; Thu, 4 May 2000 22:49:32 -0400 (EDT) Received: from dynamicsoft.com (1Cust202.tnt2.freehold.nj.da.uu.net [63.17.114.202]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA07402; Thu, 4 May 2000 22:56:09 -0400 (EDT) Message-ID: <39123A7C.8D5F65BD@dynamicsoft.com> Date: Thu, 04 May 2000 23:05:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Eber Mello , sip@lists.bell-labs.com Subject: Re: [SIP] Registrar providing location services References: <3911F289.9BF3D7D3@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Some additional comments: Igor Slepchin wrote: > > > 4) If the answer to the previous questions are YES, than the location server > > would return REDIRECT to addressK@domainM and PROXY to addressL@domainN - > > what is > > a scenario that the spec explicitly tries to avoid by enforcing that > > all contacts on a REGISTER must have the same 'action'. > > I guess the question is about what to do when the recursed Contact has > the action different from that in the first Contact. Well, that's up to > the proxy: it can overwrite that action or, if this turns out to be the > last Contact to try, it can overwrite the action from the first Contact. It should generally do whatever would happen if the domains were all served by proxies. So, given the description of the registrations: > userA@domainX registers with action=PROXY, contact1=userB@domainY > and contact2 = userC@domainZ. > userB@domainY registers with action=REDIRECT, contact=addressK@domainM > and userC@domainZ registers with action=PROXY, contact=addressL@domainN the following would happen: 1. an INVITE arrives at proxy1 for userA@domainX. Based on its registrations, it proxies this to userB@domainY and userC@domainZ 2. one invite goes to domainY and one to domainZ. domainY looks up userB, and sends a 300 redirect with Contact addressk@domainM. domainZ looks up userC, and proxies to addressL@domainN. 3. the 300 redirect arrives at the first proxy, which proxies to addressk@domainM. The proxy for domainN receives the INVITE for addressL@domainN, and does whatever its configured to do. Now, should any of these domains be served by the same proxy, the behavior should be exactly the same as if they were not served by the same proxy. So, if domainX, domainY, domainZ are all served by one proxy, that proxy would have ended up proxying the received request to addressk@domainM and addressL@domainN. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 4 23:00:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26273 for ; Thu, 4 May 2000 23:00:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F516443A9; Thu, 4 May 2000 22:54:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D806B44396 for ; Thu, 4 May 2000 22:54:06 -0400 (EDT) Received: from dynamicsoft.com (1Cust202.tnt2.freehold.nj.da.uu.net [63.17.114.202]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA07407; Thu, 4 May 2000 23:00:52 -0400 (EDT) Message-ID: <39123B97.A4633380@dynamicsoft.com> Date: Thu, 04 May 2000 23:10:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "G. Clark Brown" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Content-Language header References: <200005042223.RAA22314@center.sssi.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This is also present in rfc2543, and I believe it is an error resulting from cut and paste from HTTP, which contains this paragraph verbatim. There is no Content-Language header in SIP. This should be stricken from rfc2543bis. Thanks for pointing it out. -Jonathan R. "G. Clark Brown" wrote: > > draft-ietf-sip-rfc2543bis-00 refers to Content-Language header > in 6.46, but it does not seem to formally define this header. > Am I missing something? > > Clark > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 4 23:05:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26362 for ; Thu, 4 May 2000 23:05:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C320E443AF; Thu, 4 May 2000 22:59:28 -0400 (EDT) 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 3B5F0443AE for ; Thu, 4 May 2000 22:59:26 -0400 (EDT) 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 XAA29944; Thu, 4 May 2000 23:05:00 -0400 (EDT) Message-ID: <39123A5C.D9581F88@cs.columbia.edu> Date: Thu, 04 May 2000 23:05:00 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Content-Language header References: <200005042223.RAA22314@center.sssi.com> <39123B97.A4633380@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > This is also present in rfc2543, and I believe it is an error resulting > from cut and paste from HTTP, which contains this paragraph verbatim. > There is no Content-Language header in SIP. This should be stricken from > rfc2543bis. Thanks for pointing it out. Hmm. If we allow HTML or other objects in the SIP response, maybe Content-Language doesn't seem all that far-fetched. At least that way, I can automatically invoke the babelfish translator when I get the Spanish web-IVR menu :-) -- 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 Fri May 5 00:02:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27739 for ; Fri, 5 May 2000 00:02:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ACB7744396; Thu, 4 May 2000 23:56:28 -0400 (EDT) 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 1E6F44433E for ; Thu, 4 May 2000 23:56:26 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 5 00:00:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9913E44346; Thu, 4 May 2000 23:47:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 683FE44341 for ; Thu, 4 May 2000 23:47:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 39CD352BB; Thu, 4 May 2000 23:47:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6BB1752AB for ; Thu, 4 May 2000 23:47:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 4 23:46:39 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu May 4 23:46:39 EDT 2000 Received: from dynamicsoft.com (1Cust202.tnt2.freehold.nj.da.uu.net [63.17.114.202]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA07454; Thu, 4 May 2000 23:47:51 -0400 (EDT) Message-ID: <3912469A.2D1FE236@dynamicsoft.com> Date: Thu, 04 May 2000 23:57:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Gavrilescu Cc: Shail Bhatnagar , SIP IETF Subject: Re: [SIP] Second try : Questions about REGISTER References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Alexandru Gavrilescu wrote: > > I have a question regarding Jonathan's answer to the Shail's third > question. > Do we assume that tawatson has an account created for himself at > example.com or he is just a visitor at example.com? Whether he is visiting or not, ann account must be set up for him at example.com. Watson can't just assume a registration to example.com will succeed without knowing ahead of time what his address there is. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 5 04:34:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12271 for ; Fri, 5 May 2000 04:34:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7545B44341; Fri, 5 May 2000 04:28:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id 05E0544336 for ; Fri, 5 May 2000 04:28:39 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA30060 for ; Fri, 5 May 2000 10:28:50 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA26867 for ; Fri, 5 May 2000 10:33:57 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id KAA04791 for ; Fri, 5 May 2000 10:34:03 +0200 (MET DST) Received: from young.dinsunnet (young [188.9.34.36]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id KAA13283 for ; Fri, 5 May 2000 10:34:00 +0200 (MET DST) Received: from ms.alcatel.fr by young.dinsunnet (8.9.1b+Sun/SMI-SVR4) id KAA19138; Fri, 5 May 2000 10:34:02 +0200 (MET DST) Message-ID: <3912877A.A6F7790B@ms.alcatel.fr> Date: Fri, 05 May 2000 10:34:02 +0200 From: Francois-Xavier Guitton X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: SIP Subject: [SIP] 606 content clarification 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dear all, The RFC2543 is not very clear regarding the SDP content of a 606 - Not Acceptable response. I think it should be useful to specify in the 606 response all the media capabilities supported by the callee user agent. It will allow the caller to send directly a new INVITE with the right SDP description, without using supplementary OPTIONS discovery message, or INVITE with no SDP. Can we precise that point in the next edition of the RFC 2543 ??? Regards, Francois-Xavier Guitton (SWD/ULC) mailto:Francois-Xavier.Guitton@ms.alcatel.fr Tel: +33 (0)1 69 63 47 52 Fax: +33 (0)1 69 63 17 89 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 5 06:10:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12930 for ; Fri, 5 May 2000 06:10:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5CF874434F; Fri, 5 May 2000 06:04:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 7540044336 for ; Fri, 5 May 2000 06:04:25 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA29967; Fri, 5 May 2000 11:07:59 +0100 (BST) Message-ID: <39129CE6.3173994@ubiquity.net> Date: Fri, 05 May 2000 11:05:26 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------174113AEF5DA76046C027CCD" Subject: [SIP] Clarification to Figure 13 Bis Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------174113AEF5DA76046C027CCD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I think we all agree that the Bis draft is infinitely more readable than the plain text forerunner. A big improvement. As a result of the improved readability, I require a clarification to Figure 13 in section 11, which documents a State Transition Diagram of server for INVITE Method. My confusion mainly centres around the Failure state and subsequent transitions. 1) If the Failure state receives an ACK, a transition to Confirmed occurs. This doesn't make sense to me as there is now no way to revert to Initial state. I can see how this works for the Success state, as the BYE event, as a result of a hangup, causes the transition to Initial state. Perhaps the ACK event in the Failure state should cause a transition to Initial state? 2) A transition from Failure state to Initial state is shown on the diagram, as a dashed line. Unfortunately, this transition is unlabelled. I'm referring to the left hand dashed line, not the BYE event which joins the Success dashed line. 3) Does the diagram need to be modified in light of changes in section 4.2.5 CANCEL, which talks about the issuing of a 487 (Request Cancelled)? Presumably the 487 response is the response to the original INVITE, and a separate 200 is issued as a response to the CANCEL? 4) This leads me into more questions about Cancel in section 4.2.5. The draft states .... "A redirect or user agent server receiving a CANCEL request responds with a status of 200 (OK) if the transaction exists and a status of 481 (Transaction Does Not Exist) if not, but takes no further action. In particular, any existing calls is unaffected" What defines "transaction does not exist" from a user agent server perspective? Is a transaction deemed to be non-existent if the user agent server has issued a final response? If so then the Failure and Success states in Figure 13, presumably should issue 481 (Transaction Does Exist) as a result of CANCEL request? The user agent client is then left with two scenarios: a) Call failed at user agent server after Cancel was sent, so ACK >= 300 response b) Call succeeded at user agent server after Cancel was sent, so ACK the 200 response, and issue BYE to terminate call. So many questions, I hope that you will be able to follow my thread. :-) Thanks In Advance Phil -- Ubiquity Software Corporation http://www.ubiquity.net --------------174113AEF5DA76046C027CCD Content-Type: text/x-vcard; charset=us-ascii; name="phoffer.vcf" Content-Description: Card for Phil Hoffer Content-Disposition: attachment; filename="phoffer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hoffer;Phil tel;fax:+44 (0)1633 765601 tel;work:+44 (0)1633 765600 x-mozilla-html:TRUE url:www.ubiquity.net org:Ubiquity Software Corporation version:2.1 email;internet:phoffer@ubiquity.net title:Developer adr;quoted-printable:;;Ubiquity House=0D=0ALangstone Park=0D=0A;Newport;;NP18 2LH;UK fn:Phil Hoffer end:vcard --------------174113AEF5DA76046C027CCD-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 5 09:23:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18120 for ; Fri, 5 May 2000 09:23:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A7F084435B; Fri, 5 May 2000 09:17:52 -0400 (EDT) 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 C087944336 for ; Fri, 5 May 2000 09:17:47 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Fri, 5 May 2000 08:11:24 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJNNM6XL; Fri, 5 May 2000 09:11:15 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H3K895G3; Fri, 5 May 2000 09:11:15 -0400 Message-ID: <3912C921.D7E42893@americasm01.nt.com> Date: Fri, 05 May 2000 09:14:09 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP Content-Type: multipart/alternative; boundary="------------507B221D9C9D55504F3D7E32" Subject: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------507B221D9C9D55504F3D7E32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Regarding header syntax in the Open Issues section, it's suggested that hname and hvalue can't be *uric because of the obvious ambiguities. One suggestion is to just disallow "&" and "=". Another possibility is to just remove reserved as an alternative in the uric rule, since the text states that "All URL reserved characters in the header names and values must be escaped", i.e., there's no point in including reserved in the BNF for uric, at least for this purpose. It seems the general intent is to allow the specification of SIP headers in SIP URL's. Since the message header field-name [6.6] is defined to be a token, this suggests that it's sufficent that hname is a token as well. Unfortunately, the generic definition of field-value isn't quite so helpful: field-value = *(field-content | LWS) field-content = So perhaps the first thing to do is to replace the ABNF prose rules for field-content and TEXT-UTF8 with something more formal, e.g., field-content = quoted-string | separator | token | TEXT-UTF8char where TEXT-UTF8 = TEXT-UTF8char | LWS TEXT-UTF8char = %x21-7e | %x80-ff Ideally, we'd like to equate header values to field values, i.e., hvalue = field-value but field-value is even more general than the current 1*uric used for hvalue, so the problem gets worse. In the absence, of a more useful definition of field-content, there seem to be two approaches: 1. Follow the current spec and escape every reserved character. My own feeling is that this renders most things somewhat unreadable (if that matters), e.g., sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 becomes: sip%3aj.doe%big.com%3bmaddr%3d239.255.255.1%3bttl%3d15 2. The other approach is to use an "envelope" syntax, like quoted-string, i.e., hvalue = token | quoted-string Now only quotes have to be escaped (as a quoted-pair), but these seem to be relatively infrequent in most of the SIP examples I've seen. The rule for converting an hvalue to a field-content : a) if it's a token, it is the field-content b) if it's a quoted-string, remove the outer quotes and convert each contained quoted-pair to corresponding character. Now if quoted-string is a problem for the reason cited earlier in a similar discussion on parameter names and values (double quote marks are excluded from URI's), use a single quoted string instead. Single quote is allowed in URI's and I don't think it's used for any SIP syntax. However, this only excludes them from the outer level syntax unless we want to exclude quoted-strings from all of SIP overall. (Or maybe just from any SIP contained in URL headers.) In any case, approach 2. seems more attractive to me, but I'm not sure what current practice is in this area. Rick Workman Nortel Networks Ottawa P.S. Minor point: In section G "Changes to Be Made", a bug is recorded for the Call-ID header which proposes to change the field-content to token. I agree with the intent of the proposal, but I don't think token allows @. This may break a lot of existing implementations since the current RFC insists on @ being present. Also note that the current spec also allows @ in the local-id which may cause a bit of confusion, but I suspect most implementations just treat Call-ID as a single character sequence anyway. --------------507B221D9C9D55504F3D7E32 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Regarding header syntax in the Open Issues section, it's suggested that hname and hvalue can't be *uric because of the obvious ambiguities. One suggestion is to just disallow  "&" and "=". Another possibility is to just remove reserved as an alternative in the uric rule, since the text states that "All URL reserved characters in the header names and values must be escaped", i.e., there's no point in including reserved in the BNF for uric, at least for this purpose.

It seems the general intent is to allow the specification of SIP headers in SIP URL's. Since the message header field-name [6.6] is defined to be a token, this suggests that it's sufficent that hname is a token as well. Unfortunately, the generic definition of field-value isn't quite so helpful:

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>

So perhaps the first thing to do is to replace the ABNF prose rules for field-content and TEXT-UTF8 with something more formal, e.g.,

field-content = quoted-string | separator | token | TEXT-UTF8char

where

TEXT-UTF8 = TEXT-UTF8char | LWS
TEXT-UTF8char = %x21-7e | %x80-ff

Ideally, we'd like to equate header values to field values, i.e.,

hvalue = field-value

but field-value is even more general than the current 1*uric used for hvalue, so the problem gets worse. In the absence, of a more useful definition of field-content, there seem to be two approaches:

1. Follow the current spec and escape every reserved character. My own feeling is that this renders most things somewhat unreadable (if that matters), e.g.,

sip:j.doe@big.com;maddr=239.255.255.1;ttl=15

becomes:

sip%3aj.doe%big.com%3bmaddr%3d239.255.255.1%3bttl%3d15

2. The other approach is to use an "envelope" syntax, like quoted-string, i.e.,

hvalue = token | quoted-string

Now only quotes have to be escaped (as a quoted-pair), but these seem to be relatively infrequent in most of the SIP examples I've seen. The rule for converting an hvalue to a field-content :
a) if it's a token, it is the field-content
b) if it's a quoted-string, remove the outer quotes and convert each contained quoted-pair to corresponding character.

Now if quoted-string is a problem for the reason cited earlier in a similar discussion on parameter names and values (double quote marks are excluded from URI's), use a single quoted string instead. Single quote is allowed in URI's and I don't think it's used for any SIP syntax. However, this only excludes them from the outer level syntax unless we want to exclude quoted-strings from all of SIP overall. (Or maybe just from any SIP contained in URL headers.)

In any case, approach 2. seems more attractive to me, but I'm not sure what current practice is in this area.

Rick Workman
Nortel Networks
Ottawa
 

P.S. Minor point: In section G "Changes to Be Made", a bug is recorded for the Call-ID header which proposes to change the field-content to token. I agree with the intent of the proposal, but I don't think token allows @. This may break a lot of existing implementations since the current RFC insists on @ being present. Also note that the current spec also allows @ in the local-id which may cause a bit of confusion, but I suspect most implementations just treat Call-ID as a single character sequence anyway.
  --------------507B221D9C9D55504F3D7E32-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 5 10:00:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19310 for ; Fri, 5 May 2000 10:00:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5AE284434E; Fri, 5 May 2000 09:54:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ott-rd.ss8.ca (gw-ss8networks.storm.ca [209.87.234.122]) by lists.bell-labs.com (Postfix) with ESMTP id 9661644336 for ; Fri, 5 May 2000 09:54:41 -0400 (EDT) Received: from eberpc ([192.168.1.60]) by ott-rd.ss8.ca (8.9.3/8.9.3) with SMTP id JAA16847; Fri, 5 May 2000 09:56:45 -0400 From: "Eber Mello" To: "Jonathan Rosenberg" , "Igor Slepchin" Cc: Subject: RE: [SIP] Registrar providing location services Date: Fri, 5 May 2000 10:02:16 -0700 Message-ID: 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: <39123A7C.8D5F65BD@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Please, see my question/comment bellow. > > > Some additional comments: > > Igor Slepchin wrote: > > > > > 4) If the answer to the previous questions are YES, than the > location server > > > would return REDIRECT to addressK@domainM and PROXY to > addressL@domainN - > > > what is > > > a scenario that the spec explicitly tries to avoid by enforcing that > > > all contacts on a REGISTER must have the same 'action'. > > > > I guess the question is about what to do when the recursed Contact has > > the action different from that in the first Contact. Well, that's up to > > the proxy: it can overwrite that action or, if this turns out to be the > > last Contact to try, it can overwrite the action from the first Contact. > > It should generally do whatever would happen if the domains were all > served by proxies. So, given the description of the registrations: > > > userA@domainX registers with action=PROXY, contact1=userB@domainY > > and contact2 = userC@domainZ. > > userB@domainY registers with action=REDIRECT, contact=addressK@domainM > > and userC@domainZ registers with action=PROXY, contact=addressL@domainN > > the following would happen: > > 1. an INVITE arrives at proxy1 for userA@domainX. Based on its > registrations, it proxies this to userB@domainY and userC@domainZ > > 2. one invite goes to domainY and one to domainZ. domainY looks up > userB, and sends a 300 redirect with Contact addressk@domainM. domainZ > looks up userC, and proxies to addressL@domainN. > > 3. the 300 redirect arrives at the first proxy, which proxies to > addressk@domainM. The proxy for domainN receives the INVITE for > addressL@domainN, and does whatever its configured to do. > I guess it is also accepted for a Proxy Server to return that 300 redirect back to the UAC - if that is the best response received among all, instead of recursing on it. Better still is if the proxy server can have some internal criteria to decide whether to recurse on the returned address or not, say, if the address is not a SIP URL but rather a generic URI than the server returns the response to the UAC, otherwise it sends an Invitation to that address. Does that make sense? > > Now, should any of these domains be served by the same proxy, the > behavior should be exactly the same as if they were not served by the > same proxy. So, if domainX, domainY, domainZ are all served by one > proxy, that proxy would have ended up proxying the received request to > addressk@domainM and addressL@domainN. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Fri May 5 10:18:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19857 for ; Fri, 5 May 2000 10:18:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1E2554435D; Fri, 5 May 2000 10:12:24 -0400 (EDT) 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 8A8E144352 for ; Fri, 5 May 2000 10:12:21 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA06302; Fri, 5 May 2000 10:18:00 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id KAA19665; Fri, 5 May 2000 10:17:59 -0400 (EDT) Date: Fri, 5 May 2000 10:17:59 -0400 (EDT) Message-Id: <200005051417.KAA19665@ind.cs.columbia.edu> From: Jonathan Lennox To: "Rick Workman" Cc: SIP Subject: Re: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax In-Reply-To: <3912C921.D7E42893@americasm01.nt.com> References: <3912C921.D7E42893@americasm01.nt.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Fri, May 5 2000, "Rick Workman" wrote to "SIP" saying: > Regarding header syntax in the Open Issues section, it's suggested that > hname and hvalue can't be *uric because of the obvious ambiguities. One > suggestion is to just disallow "&" and "=". Another possibility is to > just remove reserved as an alternative in the uric rule, since the text > states that "All URL reserved characters in the header names and values > must be escaped", i.e., there's no point in including reserved in the > BNF for uric, at least for this purpose. My inclination is to just disallow "&" and "=", as well as any other syntactially obnoxious characters such as ",". I think it's most in the spirit of the URI syntax. > It seems the general intent is to allow the specification of SIP headers > in SIP URL's. Since the message header field-name [6.6] is defined to be > a token, this suggests that it's sufficent that hname is a token as > well. Unfortunately, the generic definition of field-value isn't quite > so helpful: > > field-value = *(field-content | LWS) > field-content = of either *TEXT-UTF8 or combinations of token, > separators and quoted-string> > > So perhaps the first thing to do is to replace the ABNF prose rules for > field-content and TEXT-UTF8 with something more formal, e.g., > > field-content = quoted-string | separator | token | TEXT-UTF8char > > where > > TEXT-UTF8 = TEXT-UTF8char | LWS > TEXT-UTF8char = %x21-7e | %x80-ff This isn't a complete definition of TEXT-UTF8. Maybe this is pedantic, but a proper BNF for the RFC 2279 definition of UTF8 would be: TEXT-UTF8 = LWS | %x21-7e | UTF8-NONASCII UTF8-NONASCII = %xc0-df 1UTF8-CONT | %xe0-ef 2UTF8-CONT | %xf0-f7 3UTF8-CONT | %xf8-fb 4UTF8-CONT | %xfc-fd 5UTF8-CONT UTF8-CONT : %x80-bf Splitting out UTF8-NONASCII from TEXT-UTF8 allows easy syntactic definitions of such things as quoted string bodies (qdtext), which are currently textually defined as < any TEXT-UTF8 except " or \ >: qdtext : LWS | %x21 | %x23-5b | %x5d-7e | UTF8-NONASCII The question still arises of how do you encode UTF8 field content in a header parameter. I think the only right solution is to encode first in UTF8, then to do hex %-escaping; the alternative, %-escaping 16-bit or 32-bit unicode, is just awful. > 1. Follow the current spec and escape every reserved character. My own > feeling is that this renders most things somewhat unreadable (if that > matters), e.g., > > sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 > > becomes: > > sip%3aj.doe%big.com%3bmaddr%3d239.255.255.1%3bttl%3d15 This isn't correct, because the point of escaped characters is to distinguish *URL* syntax characters from field characters. Thus, the URLs: sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 and sip:j.doe@big.com;maddr=239.255.255.1%3Bttl%3D15 are *different* URLs; the second has only a single parameter, whose name is "maddr" and whose value is "239.255.255.1;ttl=15". I think anything we do needs to be sure to preserve this distinction. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 5 12:10:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22695 for ; Fri, 5 May 2000 12:10:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6ABA44364; Fri, 5 May 2000 12:04:17 -0400 (EDT) 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 6B47144352 for ; Fri, 5 May 2000 12:04:15 -0400 (EDT) Received: from cs.columbia.edu (dhcp5.cs.columbia.edu [128.59.19.205]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA13920; Fri, 5 May 2000 12:09:51 -0400 (EDT) Message-ID: <3912E862.2E967219@cs.columbia.edu> Date: Fri, 05 May 2000 11:27:30 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox , sip@lists.bell-labs.com Subject: Re: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax References: <3912C921.D7E42893@americasm01.nt.com> <200005051417.KAA19665@ind.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > This isn't a complete definition of TEXT-UTF8. Maybe this is pedantic, but > a proper BNF for the RFC 2279 definition of UTF8 would be: > > TEXT-UTF8 = LWS > | %x21-7e > | UTF8-NONASCII > > UTF8-NONASCII = %xc0-df 1UTF8-CONT > | %xe0-ef 2UTF8-CONT > | %xf0-f7 3UTF8-CONT > | %xf8-fb 4UTF8-CONT > | %xfc-fd 5UTF8-CONT > > UTF8-CONT : %x80-bf Anything formal for TEXT-UTF8-TRIM? Maybe = TEXT-UTF8-NOLWS *TEXT-UTF8 but that doesn't express the lack of trailing LWS, although I'm not sure this actually matters from a parsing perspective. > The question still arises of how do you encode UTF8 field content in a > header parameter. I think the only right solution is to encode first in > UTF8, then to do hex %-escaping; the alternative, %-escaping 16-bit or > 32-bit unicode, is just awful. http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-05.txt describes this problem and does indeed suggest that the bytes are hex-encoded if needed. Unfortunately, it's still a pretty rough draft and unlikely to be citable in RFC2543bis. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 5 12:47:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23769 for ; Fri, 5 May 2000 12:47:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2940E4433C; Fri, 5 May 2000 12:42:09 -0400 (EDT) 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 AC20644339 for ; Fri, 5 May 2000 12:42:06 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA16162 for ; Fri, 5 May 2000 12:47:46 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id MAA21169; Fri, 5 May 2000 12:47:45 -0400 (EDT) Date: Fri, 5 May 2000 12:47:45 -0400 (EDT) Message-Id: <200005051647.MAA21169@ind.cs.columbia.edu> From: Jonathan Lennox To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: Re: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax In-Reply-To: <3912E862.2E967219@cs.columbia.edu> References: <3912C921.D7E42893@americasm01.nt.com> <200005051417.KAA19665@ind.cs.columbia.edu> <3912E862.2E967219@cs.columbia.edu> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Fri, May 5 2000, "Henning Schulzrinne" wrote to "Jonathan Lennox, sip@lists.bell-labs.com" saying: > Anything formal for TEXT-UTF8-TRIM? > > Maybe = TEXT-UTF8-NOLWS *TEXT-UTF8 TEXT-UTF8-TRIM = TEXT-UTF8-NOLWS *TEX-UTF8 TEXT-UTF8-NOLWS | TEXT-UTF8-NOLWS | ; empty string This should work. I'm not sure if you want to allow the last one. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 5 14:32:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26526 for ; Fri, 5 May 2000 14:32:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44CF444339; Fri, 5 May 2000 14:26:53 -0400 (EDT) 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 B21FB44336 for ; Fri, 5 May 2000 14:26:50 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id NAA25670 for ; Fri, 5 May 2000 13:32:16 -0500 (CDT) Received: from lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA22834 for ; Fri, 5 May 2000 13:32:14 -0500 (CDT) Received: from lmc35.lmc.ericsson.se (lmc35.lmc.ericsson.se [142.133.16.175]) by lmc.ericsson.se (8.9.2/8.9.2) with ESMTP id OAA16173 for ; Fri, 5 May 2000 14:07:15 -0400 (EDT) Received: from lmc.ericsson.se (lmcpc118309.pc.lmc.ericsson.se [142.133.11.153]) by lmc35.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K2W0ZVTA; Fri, 5 May 2000 14:06:20 -0400 Message-ID: <39130D8A.98FB3EE@lmc.ericsson.se> Date: Fri, 05 May 2000 14:06:02 -0400 From: "Mathieu Gervais (LMC)" Organization: LMC, Ericsson Research Canada X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] [Fwd: SIP URL scheme] References: <3911FEED.28717C81@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Henning Schulzrinne wrote: > Thus, whoever was dealing with the Mozilla folks can now point to the > document > http://www.isi.edu/in-notes/iana/assignments/url-schemes > to prove legitimacy. Done. See http://bugzilla.mozilla.org/show_bug.cgi?id=37637. This bug has been marked "Help Wanted" by mozilla folks, so if you are interested in implementing it, go ahead (http://www.mozilla.org/hacking/). I might try to do it. Mathieu > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > --------------------------------------------------------------- > > Subject: RE: SIP URL scheme > Date: Thu, 4 May 2000 18:18:37 -0400 > From: IANA > Reply-To: iana@iana.org > To: 'Henning Schulzrinne' > > Dear Henning, > > Thank you for notifying the IANA. This has been added. > > Best regards, > > Michelle Schipper, Administrator > IANA > > -----Original Message----- > From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of > Henning Schulzrinne > Sent: Wednesday, May 03, 2000 8:25 AM > To: iana@ISI.EDU > Cc: sip@lists.bell-labs.com; Mathieu Gervais (LMC) > Subject: SIP URL scheme > > Dear IANA: > > ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes is missing the > > sip: URL scheme defined in RFC 2543, a Proposed Standard. What is the > process of having it added to the list? > > Thank you. > > 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 Fri May 5 15:21:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27184 for ; Fri, 5 May 2000 15:21:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B88E4434E; Fri, 5 May 2000 15:15:59 -0400 (EDT) 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 8659B44336 for ; Fri, 5 May 2000 15:15:56 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Fri, 5 May 2000 12:56:17 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJNNNV8P; Fri, 5 May 2000 13:56:11 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H3K895Y3; Fri, 5 May 2000 13:56:12 -0400 Message-ID: <39130BEC.7273EAFE@americasm01.nt.com> Date: Fri, 05 May 2000 13:59:08 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox Cc: Henning Schulzrinne , sip@lists.bell-labs.com Subject: Re: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax References: <3912C921.D7E42893@americasm01.nt.com> <200005051417.KAA19665@ind.cs.columbia.edu> <3912E862.2E967219@cs.columbia.edu> <200005051647.MAA21169@ind.cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------8715E4EEA33F09C9F5850A2F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------8715E4EEA33F09C9F5850A2F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Another possibility which includes the empty string (I think this works): TEXT-UTF8 = *(TEXT-UTF8char | LWS) TEXT-UTF8-TRIM = *TEXT-UTF8char *(*LWS TEXT-UTF8char) TEXT-UTF8char = %x21-7e | UTF8-NONASCII ; same as before UTF8-NONASCII = %xc0-df 1UTF8-CONT | %xe0-ef 2UTF8-CONT | %xf0-f7 3UTF8-CONT | %xf8-fb 4UTF8-CONT | %xfc-fd 5UTF8-CONT UTF8-CONT = %x80-bf These are subtly different from the current TEXT-UTF8 and TEXT-UTF8-TRIM definitions in that the repeat has been moved inside the rule, e.g., the subject header ABNF should be changed to: Subject = ("Subject" | "s") ":" TEXT-UTF8-TRIM Rick Jonathan Lennox wrote: > On Fri, May 5 2000, "Henning Schulzrinne" wrote to "Jonathan Lennox, sip@lists.bell-labs.com" saying: > > > Anything formal for TEXT-UTF8-TRIM? > > > > Maybe = TEXT-UTF8-NOLWS *TEXT-UTF8 > > TEXT-UTF8-TRIM = TEXT-UTF8-NOLWS *TEX-UTF8 TEXT-UTF8-NOLWS > | TEXT-UTF8-NOLWS > | ; empty string > > This should work. I'm not sure if you want to allow the last one. > > -- > Jonathan Lennox > lennox@cs.columbia.edu > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------8715E4EEA33F09C9F5850A2F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Another possibility which includes the empty string (I think this works):

TEXT-UTF8 = *(TEXT-UTF8char | LWS)

TEXT-UTF8-TRIM = *TEXT-UTF8char *(*LWS TEXT-UTF8char)

TEXT-UTF8char = %x21-7e | UTF8-NONASCII

; same as before
UTF8-NONASCII = %xc0-df 1UTF8-CONT
              | %xe0-ef 2UTF8-CONT
              | %xf0-f7 3UTF8-CONT
              | %xf8-fb 4UTF8-CONT
              | %xfc-fd 5UTF8-CONT

UTF8-CONT = %x80-bf
 

These are subtly different from the current TEXT-UTF8 and TEXT-UTF8-TRIM definitions in that the repeat has been moved inside the rule, e.g., the subject header ABNF should be changed to:

Subject = ("Subject" | "s") ":" TEXT-UTF8-TRIM
 
 

Rick
 
 

Jonathan Lennox wrote:

On Fri, May 5 2000, "Henning Schulzrinne" wrote to "Jonathan Lennox, sip@lists.bell-labs.com" saying:

> Anything formal for TEXT-UTF8-TRIM?
>
> Maybe = TEXT-UTF8-NOLWS *TEXT-UTF8

TEXT-UTF8-TRIM = TEXT-UTF8-NOLWS *TEX-UTF8 TEXT-UTF8-NOLWS
               | TEXT-UTF8-NOLWS
               | ; empty string

This should work.  I'm not sure if you want to allow the last one.

--
Jonathan Lennox
lennox@cs.columbia.edu

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

--------------8715E4EEA33F09C9F5850A2F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 5 15:22:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27196 for ; Fri, 5 May 2000 15:22:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B25544354; Fri, 5 May 2000 15:16:05 -0400 (EDT) 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 C9ABE4434F for ; Fri, 5 May 2000 15:15:59 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Fri, 5 May 2000 12:33:50 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJNNNT9Y; Fri, 5 May 2000 13:33:43 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H3K895W9; Fri, 5 May 2000 13:33:44 -0400 Message-ID: <391306A8.413747B0@americasm01.nt.com> Date: Fri, 05 May 2000 13:36:40 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox Cc: SIP Subject: Re: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax References: <3912C921.D7E42893@americasm01.nt.com> <200005051417.KAA19665@ind.cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------8860A1B6104EA9BCC86DA751" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------8860A1B6104EA9BCC86DA751 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think the big picture argument you're making is that it's better to define a reserved character set for hvalue that just removes the obvious offenders ("&", "=", and ",") from the current definition. A couple of observations: 1. The text that says "All URL reserved characters in the header names and values must be escaped" has me confused. Either it's just wrong, or there really isn't much point in defining the reserved set in the definition, i.e., any characters not in the uric set of characters must be escaped. 2. If this is true, characters not in the uric set which must escaped include "<", ">", "\", double quote and space. These are present in SIP and could be included in the reserved set for hvalue to improve readability, but are either excluded or "unwise" according to the URI spec. 3. A SIP URL, including all the headers, can't contain any line breaks. This probably shouldn't come as a surprise to anyone since most people have had to deal with long http URLs in emails etc. Thanks for the clarification on the TEXTUTF-8. In my opinion, we're not pedantic enough when it comes to using ABNF. Prose rules ought to be strongly discouraged. They are often used because or lack of understanding of ABNF or sheer laziness. The few remaining cases are usually misguided attempts to capture semantics in a syntax specification. Rick Jonathan Lennox wrote: > On Fri, May 5 2000, "Rick Workman" wrote to "SIP" saying: > > > Regarding header syntax in the Open Issues section, it's suggested that > > hname and hvalue can't be *uric because of the obvious ambiguities. One > > suggestion is to just disallow "&" and "=". Another possibility is to > > just remove reserved as an alternative in the uric rule, since the text > > states that "All URL reserved characters in the header names and values > > must be escaped", i.e., there's no point in including reserved in the > > BNF for uric, at least for this purpose. > > My inclination is to just disallow "&" and "=", as well as any other > syntactially obnoxious characters such as ",". I think it's most in the > spirit of the URI syntax. > > > It seems the general intent is to allow the specification of SIP headers > > in SIP URL's. Since the message header field-name [6.6] is defined to be > > a token, this suggests that it's sufficent that hname is a token as > > well. Unfortunately, the generic definition of field-value isn't quite > > so helpful: > > > > field-value = *(field-content | LWS) > > field-content = > of either *TEXT-UTF8 or combinations of token, > > separators and quoted-string> > > > > So perhaps the first thing to do is to replace the ABNF prose rules for > > field-content and TEXT-UTF8 with something more formal, e.g., > > > > field-content = quoted-string | separator | token | TEXT-UTF8char > > > > where > > > > TEXT-UTF8 = TEXT-UTF8char | LWS > > TEXT-UTF8char = %x21-7e | %x80-ff > > This isn't a complete definition of TEXT-UTF8. Maybe this is pedantic, but > a proper BNF for the RFC 2279 definition of UTF8 would be: > > TEXT-UTF8 = LWS > | %x21-7e > | UTF8-NONASCII > > UTF8-NONASCII = %xc0-df 1UTF8-CONT > | %xe0-ef 2UTF8-CONT > | %xf0-f7 3UTF8-CONT > | %xf8-fb 4UTF8-CONT > | %xfc-fd 5UTF8-CONT > > UTF8-CONT : %x80-bf > > Splitting out UTF8-NONASCII from TEXT-UTF8 allows easy syntactic definitions > of such things as quoted string bodies (qdtext), which are currently > textually defined as < any TEXT-UTF8 except " or \ >: > > qdtext : LWS > | %x21 | %x23-5b | %x5d-7e > | UTF8-NONASCII > > The question still arises of how do you encode UTF8 field content in a > header parameter. I think the only right solution is to encode first in > UTF8, then to do hex %-escaping; the alternative, %-escaping 16-bit or > 32-bit unicode, is just awful. > > > 1. Follow the current spec and escape every reserved character. My own > > feeling is that this renders most things somewhat unreadable (if that > > matters), e.g., > > > > sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 > > > > becomes: > > > > sip%3aj.doe%big.com%3bmaddr%3d239.255.255.1%3bttl%3d15 > > This isn't correct, because the point of escaped characters is to > distinguish *URL* syntax characters from field characters. Thus, the URLs: > > sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 > > and > > sip:j.doe@big.com;maddr=239.255.255.1%3Bttl%3D15 > > are *different* URLs; the second has only a single parameter, whose name is > "maddr" and whose value is "239.255.255.1;ttl=15". I think anything we do > needs to be sure to preserve this distinction. > > -- > Jonathan Lennox > lennox@cs.columbia.edu --------------8860A1B6104EA9BCC86DA751 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I think the big picture argument you're making is that it's better to define a reserved character set for hvalue that just removes the obvious offenders ("&", "=", and ",") from the current definition. A couple of observations:

1. The text that says "All URL reserved characters in the header names and values must be escaped" has me confused. Either it's just wrong, or there really isn't much point in defining the reserved set in the definition, i.e., any characters not in the uric set of characters must be escaped.

2. If this is true, characters not in the uric set which must escaped include "<", ">", "\", double quote and space. These are present in SIP and could be included in the reserved set for hvalue to improve readability, but are either excluded or "unwise" according to the URI spec.

3. A SIP URL, including all the headers, can't contain any line breaks. This probably shouldn't come as a surprise to anyone since most people have had to deal with long http URLs in emails etc.
 

Thanks for the clarification on the TEXTUTF-8. In my opinion, we're not pedantic enough when it comes to using ABNF. Prose rules ought to be strongly discouraged. They are often used because or lack of understanding of ABNF or sheer laziness. The few remaining cases are usually misguided attempts to capture semantics in a syntax specification.

Rick
 

Jonathan Lennox wrote:

On Fri, May 5 2000, "Rick Workman" wrote to "SIP" saying:

> Regarding header syntax in the Open Issues section, it's suggested that
> hname and hvalue can't be *uric because of the obvious ambiguities. One
> suggestion is to just disallow  "&" and "=". Another possibility is to
> just remove reserved as an alternative in the uric rule, since the text
> states that "All URL reserved characters in the header names and values
> must be escaped", i.e., there's no point in including reserved in the
> BNF for uric, at least for this purpose.

My inclination is to just disallow "&" and "=", as well as any other
syntactially obnoxious characters such as ",".  I think it's most in the
spirit of the URI syntax.

> It seems the general intent is to allow the specification of SIP headers
> in SIP URL's. Since the message header field-name [6.6] is defined to be
> a token, this suggests that it's sufficent that hname is a token as
> well. Unfortunately, the generic definition of field-value isn't quite
> so helpful:
>
> 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>
>
> So perhaps the first thing to do is to replace the ABNF prose rules for
> field-content and TEXT-UTF8 with something more formal, e.g.,
>
> field-content = quoted-string | separator | token | TEXT-UTF8char
>
> where
>
> TEXT-UTF8 = TEXT-UTF8char | LWS
> TEXT-UTF8char = %x21-7e | %x80-ff

This isn't a complete definition of TEXT-UTF8.  Maybe this is pedantic, but
a proper BNF for the RFC 2279 definition of UTF8 would be:

TEXT-UTF8 = LWS
          | %x21-7e
          | UTF8-NONASCII

UTF8-NONASCII = %xc0-df 1UTF8-CONT
              | %xe0-ef 2UTF8-CONT
              | %xf0-f7 3UTF8-CONT
              | %xf8-fb 4UTF8-CONT
              | %xfc-fd 5UTF8-CONT

UTF8-CONT : %x80-bf

Splitting out UTF8-NONASCII from TEXT-UTF8 allows easy syntactic definitions
of such things as quoted string bodies (qdtext), which are currently
textually defined as < any TEXT-UTF8 except " or \ >:

qdtext : LWS
       | %x21 | %x23-5b | %x5d-7e
       | UTF8-NONASCII

The question still arises of how do you encode UTF8 field content in a
header parameter.  I think the only right solution is to encode first in
UTF8, then to do hex %-escaping; the alternative, %-escaping 16-bit or
32-bit unicode, is just awful.

> 1. Follow the current spec and escape every reserved character. My own
> feeling is that this renders most things somewhat unreadable (if that
> matters), e.g.,
>
> sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
>
> becomes:
>
> sip%3aj.doe%big.com%3bmaddr%3d239.255.255.1%3bttl%3d15

This isn't correct, because the point of escaped characters is to
distinguish *URL* syntax characters from field characters.  Thus, the URLs:

sip:j.doe@big.com;maddr=239.255.255.1;ttl=15

and

sip:j.doe@big.com;maddr=239.255.255.1%3Bttl%3D15

are *different* URLs; the second has only a single parameter, whose name is
"maddr" and whose value is "239.255.255.1;ttl=15".  I think anything we do
needs to be sure to preserve this distinction.

--
Jonathan Lennox
lennox@cs.columbia.edu

--------------8860A1B6104EA9BCC86DA751-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 5 19:03:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00903 for ; Fri, 5 May 2000 19:03:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EAFAE4433C; Fri, 5 May 2000 18:57:36 -0400 (EDT) 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 7DF2044339 for ; Fri, 5 May 2000 18:57:34 -0400 (EDT) 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 TAA15620; Fri, 5 May 2000 19:03:12 -0400 (EDT) Message-ID: <39135330.99B49770@cs.columbia.edu> Date: Fri, 05 May 2000 19:03:12 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rick Workman Cc: Jonathan Lennox , sip@lists.bell-labs.com Subject: Re: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax References: <3912C921.D7E42893@americasm01.nt.com> <200005051417.KAA19665@ind.cs.columbia.edu> <3912E862.2E967219@cs.columbia.edu> <200005051647.MAA21169@ind.cs.columbia.edu> <39130BEC.7273EAFE@americasm01.nt.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rick Workman wrote: > > Another possibility which includes the empty string (I think this > works): > > TEXT-UTF8 = *(TEXT-UTF8char | LWS) > > TEXT-UTF8-TRIM = *TEXT-UTF8char *(*LWS TEXT-UTF8char) > > TEXT-UTF8char = %x21-7e | UTF8-NONASCII > > ; same as before > UTF8-NONASCII = %xc0-df 1UTF8-CONT > | %xe0-ef 2UTF8-CONT > | %xf0-f7 3UTF8-CONT > | %xf8-fb 4UTF8-CONT > | %xfc-fd 5UTF8-CONT > > UTF8-CONT = %x80-bf > > > These are subtly different from the current TEXT-UTF8 and > TEXT-UTF8-TRIM definitions in that the repeat has been moved inside > the rule, e.g., the subject header ABNF should be changed to: > > Subject = ("Subject" | "s") ":" TEXT-UTF8-TRIM > > I updated the spec accordingly. -- 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 May 8 00:47:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18265 for ; Mon, 8 May 2000 00:47:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 020884433A; Mon, 8 May 2000 00:40:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E969944336 for ; Mon, 8 May 2000 00:40:46 -0400 (EDT) Received: from dynamicsoft.com (1Cust136.tnt1.freehold.nj.da.uu.net [63.17.113.136]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00642; Mon, 8 May 2000 00:47:49 -0400 (EDT) Message-ID: <3916493B.9FE39720@dynamicsoft.com> Date: Mon, 08 May 2000 00:57:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Content-Language header References: <200005042223.RAA22314@center.sssi.com> <39123B97.A4633380@dynamicsoft.com> <39123A5C.D9581F88@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Jonathan Rosenberg wrote: > > > > This is also present in rfc2543, and I believe it is an error resulting > > from cut and paste from HTTP, which contains this paragraph verbatim. > > There is no Content-Language header in SIP. This should be stricken from > > rfc2543bis. Thanks for pointing it out. > > Hmm. If we allow HTML or other objects in the SIP response, maybe > Content-Language doesn't seem all that far-fetched. At least that way, I > can automatically invoke the babelfish translator when I get the Spanish > web-IVR menu :-) Realistically, what are the applications for Content-Language? What would a client do differently on receiving a Spanish version vs. English? I see the value in Accept-Language, so that I get the right thing back in the first place, but Content-Language? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 00:53:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18300 for ; Mon, 8 May 2000 00:53:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8B404434B; Mon, 8 May 2000 00:47:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4B63744343 for ; Mon, 8 May 2000 00:47:15 -0400 (EDT) Received: from dynamicsoft.com (1Cust136.tnt1.freehold.nj.da.uu.net [63.17.113.136]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00647; Mon, 8 May 2000 00:54:25 -0400 (EDT) Message-ID: <39164AC7.95E58A4@dynamicsoft.com> Date: Mon, 08 May 2000 01:04:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois-Xavier Guitton Cc: SIP Subject: Re: [SIP] 606 content clarification References: <3912877A.A6F7790B@ms.alcatel.fr> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Francois-Xavier Guitton wrote: > > Dear all, > > The RFC2543 is not very clear regarding the SDP content of a 606 - Not > Acceptable response. I think it should be useful to specify in the 606 > response all the media capabilities supported by the callee user agent. > It will allow the caller to send directly a new INVITE with the right > SDP description, without using supplementary OPTIONS discovery message, > or INVITE with no SDP. Well, the response is supposed to contain Warning headers which indicate what the problem was. These give additional information, such as whether one of the media streams was unacceptable, or whether there was no common transport protocol. Right now, though, the spec doesn't seem to say anything about placement of SDP in the response. I suppose you could put it there, in which case it should be formatted the same way it would for OPTIONS. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 01:12:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19368 for ; Mon, 8 May 2000 01:12:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B4BE4434A; Mon, 8 May 2000 01:06:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 936C64433D for ; Mon, 8 May 2000 01:06:25 -0400 (EDT) Received: from dynamicsoft.com (1Cust136.tnt1.freehold.nj.da.uu.net [63.17.113.136]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA00664; Mon, 8 May 2000 01:09:56 -0400 (EDT) Message-ID: <39164E6A.EBD15785@dynamicsoft.com> Date: Mon, 08 May 2000 01:19:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Clarification to Figure 13 Bis Draft References: <39129CE6.3173994@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Phil Hoffer wrote: > > Hi All, > > I think we all agree that the Bis draft is infinitely more readable than the > plain text forerunner. A big improvement. Well, we had a postscript version for rfc2543 also, but decided not to make it available. Unfortunately, it is very difficult to guarantee consistency between the ASCII and PS versions. As the ASCII version is the absolutely correct one, we stuck with that. The next SIP revision will be the same; the final version (as will all RFCs) will be ascii text. > > As a result of the improved readability, I require a clarification to Figure 13 > in section 11, which documents a State Transition Diagram of server for > INVITE Method. Actually, I believe this diagram is confusing partly because it is combining two things - call state and transaction state. The INVITE transaction and BYE transactions are totally separate as far as retransmissions and the like are concerned. Each has its own state machinery. There is also a state machine for the call. This machine tracks the INVITE transaction state, but eventually is different once the transaction completes. > > My confusion mainly centres around the Failure state and subsequent > transitions. > > 1) If the Failure state receives an ACK, a transition to Confirmed occurs. > This doesn't make sense to me as there is now no way to revert to Initial > state. I can see how this works for the Success state, as the BYE event, > as a result of a hangup, causes the transition to Initial state. > > Perhaps the ACK event in the Failure state should cause a transition to > Initial state? > Again, confusing because two things are being combined. The INVITE transaction, upon moving to confirmed, should stay there for some amount of time, around 32s. This isn't really critical. Its main point is to make sure that any additional ACKs are treated as retransmissions. If the server machine moved immediately from failure to confirmed and then initial when an ACK came, the next ACK would appear as a "stray" ACK since the transaction state no longer exists. Stray ACKs are anyway not a big deal, but it helps to keep the state around to make sure they all get absorbed. > 2) A transition from Failure state to Initial state is shown on the diagram, as > a dashed line. Unfortunately, this transition is unlabelled. I'm referring > to the left hand dashed line, not the BYE event which joins the Success > dashed line. Hmm. not sure, actually. The labeling would make this appear to be CANCEL, but thats not correct. Henning? > > 3) Does the diagram need to be modified in light of changes in section > 4.2.5 CANCEL, which talks about the issuing of a 487 (Request Cancelled)? > Presumably the 487 response is the response to the original INVITE, and a > separate 200 is issued as a response to the CANCEL? Definitely. I believe it also needs to be reworked considering the separation of transaction state from call state. The 487 response to the original INVITE is an example of this separation. > > 4) This leads me into more questions about Cancel in section 4.2.5. > The draft states .... > > "A redirect or user agent server receiving a CANCEL request responds with a > status of 200 (OK) if the transaction exists and a status of 481 (Transaction Does > Not Exist) if not, but takes no further action. In particular, any existing calls is > unaffected" > > What defines "transaction does not exist" from a user agent server perspective? > Is a transaction deemed to be non-existent if the user agent server has issued > a final response? Transaction doesn't exist means that the UA has no current state at all for the transaction identified by the CANCEL. If the server has sent a final response, but knows about the transaction, its not a 481, but a 200 OK. > > If so then the Failure and Success states in Figure 13, presumably should issue > 481 (Transaction Does Exist) as a result of CANCEL request? No. > > The user agent client is then left with two scenarios: > > a) Call failed at user agent server after Cancel was sent, so ACK >= 300 response > b) Call succeeded at user agent server after Cancel was sent, so ACK the 200 > response, and issue BYE to terminate call. Yes. Same behavior as if there was no CANCEL, pretty much. Thats the whole idea - CANCEL "speeds things up" in getting a response from the UAS. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 01:16:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19913 for ; Mon, 8 May 2000 01:16:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFEA74433C; Mon, 8 May 2000 01:10:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6617944336 for ; Mon, 8 May 2000 01:10:18 -0400 (EDT) Received: from dynamicsoft.com (1Cust136.tnt1.freehold.nj.da.uu.net [63.17.113.136]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA00668; Mon, 8 May 2000 01:17:33 -0400 (EDT) Message-ID: <39165031.BC7306B4@dynamicsoft.com> Date: Mon, 08 May 2000 01:27:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eber Mello Cc: Igor Slepchin , sip@lists.bell-labs.com Subject: Re: [SIP] Registrar providing location services References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Eber Mello wrote: > > Please, see my question/comment bellow. > > > > > > > Some additional comments: > > > > Igor Slepchin wrote: > > > > > > > 4) If the answer to the previous questions are YES, than the > > location server > > > > would return REDIRECT to addressK@domainM and PROXY to > > addressL@domainN - > > > > what is > > > > a scenario that the spec explicitly tries to avoid by enforcing that > > > > all contacts on a REGISTER must have the same 'action'. > > > > > > I guess the question is about what to do when the recursed Contact has > > > the action different from that in the first Contact. Well, that's up to > > > the proxy: it can overwrite that action or, if this turns out to be the > > > last Contact to try, it can overwrite the action from the first Contact. > > > > It should generally do whatever would happen if the domains were all > > served by proxies. So, given the description of the registrations: > > > > > userA@domainX registers with action=PROXY, contact1=userB@domainY > > > and contact2 = userC@domainZ. > > > userB@domainY registers with action=REDIRECT, contact=addressK@domainM > > > and userC@domainZ registers with action=PROXY, contact=addressL@domainN > > > > the following would happen: > > > > 1. an INVITE arrives at proxy1 for userA@domainX. Based on its > > registrations, it proxies this to userB@domainY and userC@domainZ > > > > 2. one invite goes to domainY and one to domainZ. domainY looks up > > userB, and sends a 300 redirect with Contact addressk@domainM. domainZ > > looks up userC, and proxies to addressL@domainN. > > > > 3. the 300 redirect arrives at the first proxy, which proxies to > > addressk@domainM. The proxy for domainN receives the INVITE for > > addressL@domainN, and does whatever its configured to do. > > > > I guess it is also accepted for a Proxy Server to return that 300 redirect > back to the UAC - if that is the best response received among all, instead > of recursing on it. Sure. > Better still is if the proxy server can have some > internal > criteria to decide whether to recurse on the returned address or not, say, > if > the address is not a SIP URL but rather a generic URI than the server > returns > the response to the UAC, otherwise it sends an Invitation to that address. > Does that make sense? Yup. Proxying to http URLs is not that useful. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 02:26:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00452 for ; Mon, 8 May 2000 02:26:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81F1744337; Mon, 8 May 2000 02:20:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from octavie.dagstuhl.de (octavie.dagstuhl.de [192.76.146.1]) by lists.bell-labs.com (Postfix) with ESMTP id 366A744336 for ; Mon, 8 May 2000 02:20:22 -0400 (EDT) Received: from cs.columbia.edu (dhcp2 [192.76.146.102]) by octavie.dagstuhl.de (8.9.2/8.9.2) with ESMTP id IAA11960; Mon, 8 May 2000 08:25:59 +0200 (CEST) Message-ID: <39165FD7.EEB8A9E2@cs.columbia.edu> Date: Mon, 08 May 2000 02:33:59 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Content-Language header References: <200005042223.RAA22314@center.sssi.com> <39123B97.A4633380@dynamicsoft.com> <39123A5C.D9581F88@cs.columbia.edu> <3916493B.9FE39720@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Realistically, what are the applications for Content-Language? What > would a client do differently on receiving a Spanish version vs. > English? I see the value in Accept-Language, so that I get the right > thing back in the first place, but Content-Language? > Automatic translation is about the only application I can think of. (In HTTP, caching is probably another reason.) However, since the client is perfectly free to ignore this field, I don't see why inheriting this from HTTP is bad. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 04:46:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01379 for ; Mon, 8 May 2000 04:46:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFFE344343; Mon, 8 May 2000 04:40:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id BC17944336 for ; Mon, 8 May 2000 04:40:44 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA19215; Mon, 8 May 2000 09:44:51 +0100 (BST) Message-ID: <39167DDA.910883E2@ubiquity.net> Date: Mon, 08 May 2000 09:42:02 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] Clarification to Figure 13 Bis Draft References: <39129CE6.3173994@ubiquity.net> <39164E6A.EBD15785@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Phil Hoffer wrote: > > As a result of the improved readability, I require a clarification to Figure 13 > > in section 11, which documents a State Transition Diagram of server for > > INVITE Method. > > 2) A transition from Failure state to Initial state is shown on the diagram, as > > a dashed line. Unfortunately, this transition is unlabelled. I'm referring > > to the left hand dashed line, not the BYE event which joins the Success > > dashed line. > > Hmm. not sure, actually. The labeling would make this appear to be > CANCEL, but thats not correct. Henning? Presumably this unlabelled event could be a CANCEL as they UAC might have issued the CANCEL when the UAS was in Call Proceeding state. So the >= 300 response could cross the incoming CANCEL on the wire. Therefore a CANCEL could arrive in the Failure state. ??!! What do you think? Thanks In Advance -- Phil Hoffer Ubiquity Software Corporation Software Developer Ubiquity House Tel: +44 (0) 1633-765600 Langstone Park Fax: +44 (0) 1633-765601 Newport NP18 2LH URL: 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 May 8 09:39:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07382 for ; Mon, 8 May 2000 09:39:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81F2244338; Mon, 8 May 2000 09:32:21 -0400 (EDT) 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 13D1A44336 for ; Mon, 8 May 2000 09:32:16 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FU800H01TVM1Q@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 8 May 2000 13:38:10 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FU800G1CTVMY0@firewall.mcit.com>; Mon, 08 May 2000 13:38:10 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FU800801TUYGW@dgismtp03.wcomnet.com>; Mon, 08 May 2000 13:37:46 +0000 (GMT) Received: from dwillispc8 ([166.35.227.170]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FU8002INTUS8G@dgismtp03.wcomnet.com>; Mon, 08 May 2000 13:37:46 +0000 (GMT) Date: Mon, 08 May 2000 08:37:34 -0500 From: Dean Willis To: iesg-secretary@ietf.org, IETF SIP Cc: Allison Mankin , Scott Bradner Message-id: <000001bfb8f2$91c582a0$aae323a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [SIP] Minutes, SIP WG, IETF 47 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Final minutes of SIP WG, IETF 47. Notes recorded by Tom Taylor, edited by Dean Willis. HTML version posted to http://www.softarmor.com/sipwg/meets/IETF47/notes/final-minutes.html. There were two review cycles on the list. Minutes of SIP Working Group Meetings, IETF 47. There were two sessions and thirty drafts. The meeting was chaired by WG chairs Jonathan Rosenberg, Joerg Ott, and Dean Willis. Tom Taylor recorded notes, and Dean Willis edited these into minutes. 1. Agenda Bashing ================= The proposed agenda was accepted. Presenters from Kyoto University asked to be added to the agenda. The request was denied because their draft had not been submitted by the meeting cutoff date and the agenda was very full. 2. Status ========= Dean Willis presented a summary of status of the WG work items, followed by a brief discussion of potential charter items. There was discussion as to whether the DCS drafts would be considered for adoption by the WG. The current drafts still have RFC2026 complienace issues preventing WG adoption as work items, but these issues may soon be resolved. The general consensus seems that several of the DCS drafts are likely to be adopted once the IPS is resolved. The WG indicated consensus to adopt several tasks as chartered WG activities, including: SIP server features (standards track) Call flows (informational) Session Timer (standards track) Reliability of provisional messages (standards track) SIP-T efforts: ISUP MIME types (standards) ISUP mapping (undetermined) Single Line Extension (undetermined) Guidelines for Extensions. As a general note regarding the management of the work of the WG: Jonathan Rosenberg is attempting to assemble teams around specific work items, with the proviso that individual participants should not be over-committed. The "single line extension" team is an example of this. 3. Summary of Current Discussion On The List ============================================ Jonathan Rosenberg summarized the status of discussion of a number of current issues. 3.1 draft-nair-sip-dhcp-00.txt No issues have been raised on the list, nor comments received from the DHCP WG. The fast-track procedure applied to this work appears to be acceptable to the SIP WG. 3.2 Content In INVITE Discussion in late December of how to include of content such as JPEG images in INVITEs brought out a number of points: -- whether to include the actual content, include it indirectly through provision of a URI, or include it indirectly as a media stream -- location of the content, in a header or in the body -- the need to identify how the content is to be used. Jonathan perceived no consensus on these items, due to lack of comment on specific proposals made to the list. 3.3 WWW-Authenticate Syntax There is a proposal before the list, but no comments have been received. 3.4 tel:// vs. sip:// URLs Jonathan emphasized the importance of the issue, discussion of which has stalled. He would like to see a new push to resolve it. 3.5 URL Parameters For Telephone Numbers A couple of issues have been discussed under this heading: how to indicate that the number shown is the result of an LNP lookup, and how to indicate private dialing plans. Again, Jonathan would like to see a renewed effort to resolve these issues. 3.6 To Quote Or Not To Quote: Digest-URI Robert Sparks commented that most implementations use quotes around the digest-URI. Usage for other fields is variable. He suggests that all fields be quoted. 3.7 Re-INVITE Glare Jonathan noted that three proposals are on the table for handling of coincident re-INVITEs. Scott Petrack noted the need for a solution that works with more than two parties. Jonathan responded that SIP states are shared only on a per-call-leg basis, except possibly in the case of multicast, so multileg coincidental invites may not be an issue. [A couple of points in Jonathan's charts were skipped because they are being considered by the SIP security task force.] 3.8 When To Send 183 Response Jonathan presented the rules for use of the 183 response which had come out of discussion on the list. A brief discussion followed, in which a problem with the first rule was noted and resolved. 3.9 Overlap Dialling Jonathan noted that there was no easy solution to the possibility of forking for a call in which overlap dialling is being used. David Oran suggested that when the gateway rejects the first call, it should return a contact which redirects all subsequent INVITEs to the same gateway. Jonathan noted that this changed the meaning of the Contact: header slightly, but its usage remains within acceptable bounds. 3.10 Early Media Criticality Jonathan noted a continuing unresolved issue of how to distinguish between critical and non-critical early media. In general Jonathan intends to put out notes to the list to stimulate further discussion of the open issues. 4. Status Of I-Ds (Jonathan Rosenberg)[charts] ====================================== 4.1 Caller Preferences (draft-ietf-sip-callerprefs-01.txt) Jonathan summarized a number of changes in the current draft. There have been no objections to the use of case-sensitive matching. The draft is due to go to the IESG, but Jonathan is looking for volunteeers to check it out first. 4.2 Supported: Header (draft-ietf-sip-serverfeatures-02.txt) The draft has undergone a major overhaul. The one open point had to do with use of the header with ACK. This has been fixed and the draft has been forwarded to the IESG. 4.3 Reliable Provisional Responses (draft-ietf-sip-100rel-00.txt) A number of open issues still remain. -- cumulative acknowledgements: looking for an application to justify inclusion of the mechanism -- response to PRACK: retain mechanism -- CANCEL for PRACK: disallow We are looking to pass this document to the IESG as a Proposed Standard by mid-April. 4.4 Guidelines For Authors Of SIP Extensions (draft-rosenberg-sip-guidelines-00.txt) Jonathan proposed that this be a WG work item. It would eventually become a BCP, but not for another year. For now it would be a living document as the WG accumulates experience. The sense of the meeting was to adopt the work item, but there were mixed views on how quickly it should be given formal status, with some arguing for near-term RFC status. This point will be taken to the list. Jonathan has volunteered to maintain the document if the WG chooses to make it a long-term project as he proposes. 4.5 Third-Party Call Control (draft-rosenberg-sip-3pcc-00.txt) This document has a number of dependencies, and various models of control are possible. In general the work does not involve an extension to SIP, but only a description of the usage of its mechanisms. For this reason Jonathan does not propose that it be a WG work item, but would like people to comment on it. 5. DCS Drafts ============= 5.1 Resource Reservation (Bill Marshall) [charts] (draft-manyfolks-sip-resource-00.txt) This draft came about through the compromise merger of draft-ietf-mmusic-qos-00.txt and draft-dcsgroup-sip-resource-01.txt. The two-stage INVITE has been discarded. SDP enhancements in support of QOS and security negotiation include two new attributes (a=qos: and a=security:), with syntax provided for confirmation that the requested attribute values have been granted. Extensions to SIP in support of the negotiation of these attributes are covered in the same document as the SDP changes, with AD approval. SIP extensions include use of a header indicating that preconditions have been met. The question was raised, whether there was any problem with using the a=qos: attribute with provisional responses to allow the invitee to set preconditions. Bill made the point that the first user of the attribute has to know whether the other end would understand it. 5.2 Caller Identity (Flemming Andreasen) [charts] (draft-dcsgroup-sip-privacy-01.txt) Flemming summarized changes in the draft. Earlier work has been extended to recognize the possibility of boundaries between proxies. In geneal, rather than requiring a nounary proxy to remove calling party information, any proxy may encrypt the field and list itself as an authenticator. A new header, "Remote-Party-ID", has been defined. The set of possible operator services has been generalized. Scott Petrack suggested that a specific tag for operator services might not be in the spirit of SIP. Jonathan agreed that an alternate approach might be possible. The basic idea, as always in SIP, is to define a small set of reusable features rather than a variety of specialized ones. 5.3 Distributing Call State (Bill Marshall) [charts] (draft-dcsgroup-sip-state-01.txt) The mechanism has changed completely since the previous draft, in an attempt to make it more general. The draft now takes care to distinguish between transaction state, connection state, and call state. The rules for including the "State" header have been simplified. There was a comment to the effect that the state information must include the information necessary to ensure that it is not used for a different call from the one which generated it. 5.4 Proxy-to-Proxy Extensions (Mike Mannette) [charts] (draft-dcsgroup-sip-proxy-proxy-01.txt) Mike reviewed the changes from the previous draft. LNP support has been provided and hostport is now a required field in the "Gate" header. The "Billing-Info" and "Billing-Id" headers are unchanged. 5.5 Media Authorization (B. Beser) [charts] (draft-dcsgroup-sip-call-auth-01.txt) This draft addresses the need for a per-call mechanism to authorize the flow of media. The new draft has been changed to focus only on the client. The former "DCS-Local-Gate" header has been renamed to "Media-Auth". The content has been generalized to hexadecimal. 6. Subscribe-Notify (Adam Roach) ========================================== (draft-roach-sip-subscribe-notify-00.txt) Motivation: there is a need for a central definition of concepts which have been mentioned in various documents. The draft formalizes the methods and headers associated with subscription and notification. Distinctions are made between call-related and resource-related subscriptions, with the latter typically being of interest to third parties. Rules are set down for notifications and for duration of subscriptions. The author attempted to avoid disruption to PINT, but it might be possible to combine the PINT work with this new material. Scott Petrack noted that PINT had spent a great deal of time working to make their mechanisms sufficiently generic. He urged Adam to review the PINT archives. Unsubscription proved to be a tricky topic, and PINT found it preferable to list events in bodies rather than in headers. Scott and Adam will discuss this further off-line. Henry Sinnreich asked what measures had been taken to coordinate with the Instant Messaging and Presence (IMPP) WG. Jonathan replied that IMPP is addressing a different problem and had already judged SIP to be unsuitable for their purposes. He also recalled that a general subscription/notification BOF was held, but nothing came out of it because the problem was too broad. Scott Petrack noted that PINT will change if necessary to conform to SIP. An example subscription/notification service was presented, where the caller is rung back when the callee becomes free. There are open issues where further work is required. Jonathan proposed that another task force be set up on the Egroup mail server, to refine the problem statement. Michael Thomas questioned whether SIP really needed an asynchronous method of completing a call when the current protocol can support a blocking approach. 7. Mobility (S. Baba) [charts] ========================= (draft-itsumo-sip-mobility-req-00.txt) The draft provides requirements, open issues, and relevant work items in SIP and other WGs. The requirements are organized on a functional basis. Addressing the charts, Lawrence Conroy asked what was meant by the requirement to "utilize" CDMA soft hand-off. He saw this as invisible at the IP level. The presenter pointed out that the process might involve multiple IP addresses for the same UA. This would represent a major extension to SIP. James Polk noted that the forthcoming Location Information BOF might be relevant to this problem. [end of first session] 8. Review Of Charter Work Items (Dean Willis) [charts] =============================== Dean asked for comments on the proposed work items before the WG chairs reviewed them and passed the results of the review on to the list. There were no comments. 9. INFO Method, Session Timer, 183 Session Progress (Steve Donovan) [charts] =================================================== 9.1 INFO Method Work on the INFO method, draft-ietf-sip-info-method-01.txt, is basically done. 9.2 Session Timer The Session Timer draft (draft-ietf-sip-session-timer-01.txt) underwent significant change to reflect the new "Supported" header. Some issues remain before WG Last Call: -- refreshing of the timer. Jonathan suggested that this be done by re-INVITE, rather than a new method. Agreed. -- Session-Expires header problematic in anything but INVITE -- will be allowed with INVITE only. -- Can a proxy add Required headers? -- could end up with multiple Required headers if the UAC also includes one. This doesn't seem to break anything, but there is an interaction with authorization. In the absence of comment from anyone but Jonathan, this should be checked out on the list. -- the question was asked: what happens if the called UA includes Session-Expires with a re-INVITE and it contradicts the one set by the calling UA? Steve suggested that it would be up to the implementation to sort this out. The list will be invited to comment. Next steps: -- agreed that this becomes an official WG work item -- submit shortly to WG Last Call. 9.3 183 Session Progress draft-ietf-sip-183-00.txt has a lot of dependencies, resulting in improved understanding of the issues. It may be used for early media and for pre-conditions. Summarizing the extensions involved: -- full session description bodies in 18x responses -- add the 183 response -- provide the "Session" header to indicate the purpose of the session description body The first two items are in 2543 bis already. It is proposed that the Session header draft be refined to narrow its focus, taking advantage of the 183 documentation. 10. Call Control (Robert Sparks) [charts] ================================ 10.1 Framework For Call Control Extensions (draft-campbell-sip-cc-framework-00.txt) Needs to be aligned with the guidelines. 10.2 Call Transfer (draft-sparks-sip-cc-transfer-00.txt) Proposes a new TRANSFER method (not BYE ALSO), which does not alter the original session. Open issues: -- name of the method. Jonathan interjected that he does not want to build protocols for specific services, hence the method should have a more abstract name and definition. Dean Willis suggested "Introduce". -- whether the method can carry bodies -- authentication. Dean Willis suggested an "Introduced-By" header, signed by the transferor. 10.3 Service Context -- Use of the SIP Request URI (draft-campbell-sip-service-control-00.txt) This is an informational draft proposing the transmission of service context through use of a distinctive Request-URI. Robert provided an example application and described the advantages of the mechanism. David Oran was unclear on the intent of the work. He noted that it takes the opposite approach to that of HTML, by using the left side of the URL rather than the right. The syntax conflict could make the result different depending on the server. Dean Willis pointed out that SMTP also uses the left hand side, and that web URLs lack the @ and therefore HAVE no left hand side. Robert responded that the URL is intended to be an opaque entity bound as a whole against a particular service. David agreed that under these conditions the format was acceptable. The authors were encouraged to submit this work for informational RFC status. This work was not adopted as a group effort of the SIP WG. 10.4 Call Flow Examples (Presentd by Robert Sparks) (draft-ietf-sip-call-flows-00a.txt) The draft has had a number of updates. Please forward any further flows to Alan Johnston (alan.johnston@wcom.com). Jonathan noted that the document is getting too large to handle easily. He proposes to farm out subsections to volunteers to review. Ideally they should simulate the flows to validate them. Alan Johnston will coordinate the work. There is an issue with dependencies on work in progress. The document will be partitioned so that the stable part is processed first. 11. IETF SIP MIB (David Walker) (draft-ietf-sip-mib-00.txt) Issue: the document is 70 pages long. Can this be reduced? It covers RFC 2543 plus the INFO method and the 183 response. Items are defined within configuration, statistics, and notification groups for each of the UAC, UAS, proxy, registrar, and redirect server, except that elements common to all of these are grouped separately. (Nothing has been defined as yet to be specific to the redirect server.) Concern: too many measurements. Discussion of this brought out the following: -- measurements should be defined only if there is a stated use for them -- they are used as a troubleshooting tool, but a message history tool would do a better job David will send a note to the list to provoke further discussion. Comments on how measurements are used will be welcome. The note will also raise a number of other questions for comment. The current draft contains a couple of known errors. 12. BCP For SIP to ISUP Mapping (Gonzalo Camarillo) [charts] (draft-camarillo-sip-isup-bcp-00.txt) This draft covers requirements, call flow examples, and the mapping of parameters between the two protocols. Gonzalo went over the changes to the draft: -- new name -- additional extension: umbrella REQUIRE -- refinement of scope -- a discussion of SIP bridging between ISUP networks -- corrections to the handling of overlap signalling -- added examples. He presented a walk-through of the overlap signalling case. There is a lot of messaging, but, unlike in the previous draft, it works. There is an open issue of how to control routing of overlap signalling in the case of a stateless proxy forwarding to loadsharing MGCs. A question was asked: how is connection redundancy handled -- for example, UA multihoming. What if the successive messages arrive at different answers. The reply was that this issue was out of scope of the draft. Jonathan remarked that SCTP transport for SIP is a topic for the future. Gonzalo concurrently presented a report on the status of the SIP-T work. It was noted that of the SIP-T work, the highest priority is to obtain approval of the ISUP MIME types document. This is currently planned for May 2000. 13. SIP Mapping Of MLPP (James Polk) [charts] (draft-polk-sip-mlpp-mapping-00.txt) There is a mismatch between SIP "priority" levels and MLPP levels. The draft proposals are to add a level and add administrative hooks. Jonathan remarked that the standard is not the place to specify the administrative hooks -- they belong in an RFP. Subsequent discussion brought out two points: -- added priority level in RFC 2543bis -- additional document describing operation of MLPP. This would cover a number of items besides SIP, so it should not be a SIP WG document. Jonathan also wondered whether MLPP really impacts SIP except at the gateway, since it is concerned with preemption of limited call resources in the face of higher-priority demand and IP resources are not so obviously limited as circuits. Brian Rosen disagreed, pointing out that MLPP is not only about preeemption. The outcome of the discussion was consensus to discuss adding another priority level to 2543bis, or possibly adding "token" to the grammar allowing arbitrary extension. This will require list review. James Polk may submit a detailed fraft showing how the SIP priority levels can be used to implement MLPP requirements. 14. Update On ISUP MIME Types (Lyndon Ong) (draft-ong-sip-qsig-mime-00.txt) The draft has one open issue: the amount of ISUP version information required. Followup is occuring in the SIP-T subteam and will be reviewed on the main list when ready. 15. SIP and QOS (Henry Sinnreich) [charts] (draft-sinnreich-sip-qos-osp-01.txt) Henry presented a list of "to do" items associated with the work. He hypothesized that a new WG may be required. As evidence of this he cited the need for a framework, within which different QOS models might operate. Radhika Roy mentioned that ITU-T Study Group 16 is also doing QOS work, and the two groups could share their results. Henry agreed that this was possible. Patrice Calhoun asked about the relationship between QOS and OSP (Open Settlement Protocol, which appeared on Henry's charts). Henry indicated that OSP was relevant because it supports the clearing house model of settlements, and the latter differs from the AAA WG model. Melinda Shore remarked that overall (thinking also of DCS) there seemed to be some strange QOS work going on, driven by charging models. Hooks within SIP are in scope for SIP WG discussion, but the general topic of QOS for VoIP is out of scope. Continuing in his presentation, Henry presented call flows showing the tight coupling between signalling, QOS, and AAA. Jonathan remarked again that ONLY changes required to SIP are within the SIP WG's scope. Dave Oran observed that DCS covers the "push model" of QOS: policy is pushed to the enforcement point. There is a need to develop a system for the pull model, with open security issues standing in the way. Dave proposed COPS-PR for this role. Dean Willis suggested that perhaps the Transport Area WG could tackle the larger problem. Jonathan proposed discussing the matter with the ADs. 16. SIP Through Firewalls and NATs (Jonathan Rosenberg) [charts] (draft-rosenberg-sip-firewalls-00.txt) Jonathan noted that the topic of firewall/NAT traversal is being covered by the foglamps BOF. The question is whether the SIP WG wants to do an Informational RFC on the specific topic of SIP operation through these barriers. Dean Willis suggested that the question of whether this work belongs in SIP is of the same order as whether MLPP does -- that is, both are enablements for SIP within specific sectors. There was a weak hum in favour of the work item. 17. Usage of TRIP For Gateway Registration (Jonathan Rosenberg) (draft-rs-trip-gw-00.txt) This was simply an alert to the topic, which had been raised in the meeting of the IPTEL WG the previous day. 18. Transferring User Control Information In SIP REGISTER Payloads (Jonathan Rosenberg) (draft-lennox-sip-reg-payload-00.txt) We need a way to pass scripts from the client to the server. This draft is the same as the original version a year ago, with minor changes. There are several open issues. Jonathan asked "Should this be a SIP work item?", which started a lively discussion. Radhika Roy suggested there was a relationship to and potential impact on mobility; Jonathan disagreed. Lawrence Conroy wondered how the scripts would be authenticated. Dean Willis mentioned several approaches that have been suggested. Dean put the question: "even with the other alternatives, is it useful to do this function via REGISTER?" There was a slight hum in favour, no opposition, with most registering no opinion. The work was accepted subject to approval on the list. 19. Finding A SIP Server With SLP (James Kempf) (draft-kempf-sip-findsrv-00.txt) The intention is to add a template to the IANA service type registry. Motivation: there are several ways to locate a SIP server through DNS -- for example, by use of a naming convention. The method presented allows location by characteristics. This is useful because different proxies in a domain can have different characteristics. The approach taken is to have one SLP abstract service type: "service-sip", with two concrete service types. Jim presented an example: find a registrar supporting CPL. An open issue is how to handle incoming calls. With other methods of DNS usage, one can parse down the hierarchy of server names. With SLP it may be necessary to use SIP forking or multicast. Should this be a WG work item or an individual draft? IANA approval requires RFC documentation and approval by Eric Guttman (servloc Chair). Comments on the draft can go to Jim directly or to the list. Jonathan noted that this is one of many possible methods, but that's OK. There is certainly no point in discussing whether this work should go forward as opposed to some other approach. The consensus was to not adopt this as a WG task at this time, but to follow the work as it matures and reconsider at a futue point. 20. CGI Interface (Jonathan Rosenberg) (draft-lennox-sip-cgi-03.txt) The draft is being cleaned up. A couple of issues have been resolved. There are alternative methods for transfer of the CGI scripts. There appears to be no intent to make this a WG item at this time. 21. Distributed Multipoint Conferences Using SIP (Jeff Mark) [charts] (draft-mark-sip-dmcs-00.txt) Jeff provided some examples, showing manipulation of full mesh conferences. Is there SIP interest in further such full mesh work? Jonathan noted that conference control is not part of the SIP WG mandate. The problem of topology management is overly complicated because call control should be separated from link state propagation. The latter is not something SIP is good at. Jonathan will organize a first pass at rearchitecting the proposal, but there are other approaches to multi-party conferencing that may prove worth discussing. -- Dean Willis dwillis@greycouncil.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 Mon May 8 12:38:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11593 for ; Mon, 8 May 2000 12:38:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C80744339; Mon, 8 May 2000 12:32:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lists.bell-labs.com (Postfix) with ESMTP id 8B83544336 for ; Mon, 8 May 2000 12:32:20 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Mon, 8 May 2000 11:38:23 -0400 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQHR13GV; Mon, 8 May 2000 11:38:16 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K365NW8K; Mon, 8 May 2000 11:38:18 -0400 Message-ID: <3916E02E.D3176BB4@americasm01.nt.com> Date: Mon, 08 May 2000 11:41:34 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com References: <3912C921.D7E42893@americasm01.nt.com> <200005051417.KAA19665@ind.cs.columbia.edu> <3912E862.2E967219@cs.columbia.edu> <200005051647.MAA21169@ind.cs.columbia.edu> <39130BEC.7273EAFE@americasm01.nt.com> <39135330.99B49770@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------68AB1D8811F55E1246432D85" Subject: [SIP] URI's in SIP messages Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------68AB1D8811F55E1246432D85 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The current SIP BNF allows the general form of URI (or URI-reference?) to be used in the request line and various headers. Observations and questions: 1. A valid form of URI (RFC 2396)is the empty sequence since: URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] This would permit the request line and various headers (To, From, Contact. ..) without an address specification which doesn't seem to make much sense. RFC 2396 specifies that the empty sequence URI refers to the start of the current document; is there any corresponding abstraction for SIP transcations? 2. The relative URI references a resource relative to a base URI of a hierarchial scheme. So a similar question: is this a useful concept for SIP sessions? 3. Finally RFC 2396 states (my emphasis): "When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI." So this very general URI seems to have a number of properties which don't seem to be relevant when used in place of a SIP URL. Since generality often has a price either in implementation or specification, i.e., lots of semantic constraints, does it make sense to restrict the syntactic form of URI used in place of a SIP URL, e.g., to the absolute-URI form? Rick Workman Nortel Networks Ottawa --------------68AB1D8811F55E1246432D85 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
The current SIP BNF allows the general form of URI (or URI-reference?) to be used in the request line and various headers. Observations and questions:

1. A valid form of URI (RFC 2396)is the empty sequence since:

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

This would permit the request line and various headers (To, From, Contact. ..) without an address specification which doesn't seem to make much sense. RFC 2396 specifies that the empty sequence URI refers to the start of the current document; is there any corresponding abstraction for SIP transcations?

2. The relative URI references a resource relative to a base URI of a hierarchial scheme. So a similar question: is this a useful concept for SIP sessions?

3. Finally RFC 2396 states (my emphasis):
  "When a URI reference is used to perform a retrieval action on the
   identified resource, the optional fragment identifier, separated from
   the URI by a crosshatch ("#") character, consists of additional
   reference information to be interpreted by the user agent after the
   retrieval action has been successfully completed.  As such, it is not
   part of a URI, but is often used in conjunction with a URI."
 
 

So this very general URI seems to have a number of properties which don't seem to be relevant when used in place of a SIP URL. Since generality often has a price either in implementation or specification, i.e., lots of semantic constraints, does it make sense to restrict the syntactic form of URI used in place of a SIP URL, e.g., to the absolute-URI form?
 

Rick Workman
Nortel Networks
Ottawa --------------68AB1D8811F55E1246432D85-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 14:34:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14651 for ; Mon, 8 May 2000 14:34:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A7B594434F; Mon, 8 May 2000 14:28:00 -0400 (EDT) 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 2013A44336 for ; Mon, 8 May 2000 14:27:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 14:32:49 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7BF6944341; Mon, 8 May 2000 14:19:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3F8A444345 for ; Mon, 8 May 2000 14:19:39 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 53CEE52AB; Mon, 8 May 2000 14:19:34 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 7FCAD52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20331 for ; Mon, 8 May 2000 08:08:06 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 08:01:10 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 08:01:08 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA156820; Mon, 8 May 2000 21:55:43 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA64550; Mon, 8 May 2000 22:01:00 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041FE13 ; Mon, 8 May 2000 22:00:48 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:32 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: "headers" in SIP-URL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Henning Schulzrinne wrote: > > In a redirect, you can play tricks such as adding new headers to the > next, redirected call. (For example, the redirect server could provide > the password for another call.) While I doubt that it is used right now, > it seems like a feature worth having around. Are these headers copied to the next request - as long as one of the following is not specified : Call-ID, From, To and CSeq, Via ?? Any security issues with this ?? Thanks, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 14:35:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14709 for ; Mon, 8 May 2000 14:35:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D30944358; Mon, 8 May 2000 14:28:03 -0400 (EDT) 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 69A1D44345 for ; Mon, 8 May 2000 14:27:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 14:32:49 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0761444344; Mon, 8 May 2000 14:19:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id CAE2F44341 for ; Mon, 8 May 2000 14:19:38 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0C38852D2; Mon, 8 May 2000 14:19:32 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id D419F52B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id MAA26901 for ; Mon, 8 May 2000 12:42:17 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 12:39:48 EDT 2000 Received: from toto.oz.is ([193.4.211.170]) by dusty; Mon May 8 12:39:47 EDT 2000 Received: from kansas.intranet.oz.is (scarecrow.oz.is [193.4.211.95]) by toto.oz.is (8.9.3/8.9.3) with ESMTP id QAA23282 for ; Mon, 8 May 2000 16:44:29 GMT From: ozsip@oz.com Subject: Re: [SIP] Content-Language header To: sip@lists.research.bell-labs.com X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Mon, 8 May 2000 16:36:58 +0000 X-MIMETrack: Serialize by Router on OZ-ICE/OZ-Inc(Release 5.0.2c (Intl)|2 February 2000) at 08.05.2000 16:37:07 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Realistically, what are the applications for Content-Language? What > would a client do differently on receiving a Spanish version vs. > English? I see the value in Accept-Language, so that I get the right > thing back in the first place, but Content-Language? Perhaps if you would send a SIP invitation with "Content-Language: Spanish" to sip:support@somewhere.com, you would prefer the proxy at somewhere.com to route your call to a support representative who spoke spanish. -David H. Brandt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 14:46:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15022 for ; Mon, 8 May 2000 14:46:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C94C44366; Mon, 8 May 2000 14:40:02 -0400 (EDT) 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 5786644364 for ; Mon, 8 May 2000 14:39:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 14:45:59 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 39AED44345; Mon, 8 May 2000 14:19:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 8B7D744346 for ; Mon, 8 May 2000 14:19:40 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 069BC52D6; Mon, 8 May 2000 14:19:36 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id A22BD52D5 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20278 for ; Mon, 8 May 2000 08:06:19 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 08:01:33 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 08:01:32 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA156680; Mon, 8 May 2000 21:56:06 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA49584; Mon, 8 May 2000 22:01:23 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00420777 ; Mon, 8 May 2000 22:01:12 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Anoop_Tripathi@mw.3com.com (Anoop Tripathi) Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:34 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Why must a stateless proxy insert a Via header for itself. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Anoop, Just call your proxy a firewall, and then you don't have to. Though, be advised that the next downstream UAS will add a 'received' parameter to the topmost 'via' so you will see all subsequent responses to this request. regards, david > > Currently, the RFC states that every server in the path of a request must add > itself as a Via header. > > As a stateless proxy, if this restriction is removed then I can process more > calls with faster call setup times. > > So , can we make inserting itself as a Via optional for a stateless proxy. > > > Thanks, > > Anoop > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 14:48:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15112 for ; Mon, 8 May 2000 14:48:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 431D24436B; Mon, 8 May 2000 14:40:05 -0400 (EDT) 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 A0BE044365 for ; Mon, 8 May 2000 14:39:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 14:45:58 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9AAEE4434A; Mon, 8 May 2000 14:19:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3FC2B44348 for ; Mon, 8 May 2000 14:19:40 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3635552D4; Mon, 8 May 2000 14:19:38 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 680A852C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20323 for ; Mon, 8 May 2000 08:07:51 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:58:36 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:58:34 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA242262; Mon, 8 May 2000 21:53:09 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA31400; Mon, 8 May 2000 21:58:26 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041C43F ; Mon, 8 May 2000 21:58:20 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: adam.roach@ericsson.com, sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:24 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] draft-roach-sip-acb, draft-roach-sip-subscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Some quick comments: - It would be nice to align the event notification as much as possible with PINT, since PINT is intended as a SIP profile. If their model is broken, it needs to be fixed. (It may well may sense to extract the event mechanism from PINT and have a common draft.) - Expires: It might be cleaner to structure this similar to the Contact mechanism in REGISTER. This also makes it possible to perform several actions atomically. Something like Event: waterboiling ;expires=3600 , dinnerdone;expires=7200 (I'm not sure that putting this is in the header is necessarily the best solution, but that's a separate discussion.) -- 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 May 8 14:49:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15162 for ; Mon, 8 May 2000 14:49:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5700244364; Mon, 8 May 2000 14:40:13 -0400 (EDT) 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 E27EE44367 for ; Mon, 8 May 2000 14:39:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 14:45:58 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0848844347; Mon, 8 May 2000 14:19:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id AEB4444346 for ; Mon, 8 May 2000 14:19:39 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A6A2B52BB; Mon, 8 May 2000 14:19:35 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id D8AA452D4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20432 for ; Mon, 8 May 2000 08:11:22 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 08:00:31 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 08:00:28 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA51852 for ; Mon, 8 May 2000 21:55:03 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA42010 for ; Mon, 8 May 2000 22:00:20 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041F1E2 ; Mon, 8 May 2000 22:00:17 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "'sip@lists.research.bell-labs.com'" Message-ID: Date: Mon, 8 May 2000 14:10:34 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] SIP & RTSP interworking? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com What would be the proper (or suggested) procedure to tie a SIP session to an RTSP session? What I'd like to do is setup a session with SIP (via an INVITE), then control streaming aspects via RTSP (i.e. play, pause, stop etc.). However, its not clear to me how I tie the RTSP session id to the previously established SIP session. Thanks. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:00:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15466 for ; Mon, 8 May 2000 15:00:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3318644367; Mon, 8 May 2000 14:54:02 -0400 (EDT) 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 E4F2E44354 for ; Mon, 8 May 2000 14:53:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 14:59:08 EDT 2000 Received: by lists.bell-labs.com (Postfix) id AD6C744352; Mon, 8 May 2000 14:20:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C13CA44349 for ; Mon, 8 May 2000 14:19:51 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C28A552B6; Mon, 8 May 2000 14:19:43 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 552BE52C4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20374 for ; Mon, 8 May 2000 08:09:07 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:56:36 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:56:34 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAB33454; Mon, 8 May 2000 21:51:08 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA68278; Mon, 8 May 2000 21:56:23 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00419344 ; Mon, 8 May 2000 21:56:15 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: leslie@lgcit.com Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:19 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Question on RTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Dohoon Kim wrote: > > The caller lists the codecs avaiable in the session description in an > INIVTE, > then the callee lists the codecs which can be supported among them. > > If multiple codec is available in a media stream, such as > > m=audio 1 RTP/AVP 0 1 > > which codec should be selected by caller, Any one they want. > > and how can the callee know which codec is selected? By the payload type number in the RTP packets. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 15:02:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15596 for ; Mon, 8 May 2000 15:02:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58D8E4437E; Mon, 8 May 2000 14:54:08 -0400 (EDT) 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 C451244375 for ; Mon, 8 May 2000 14:53:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 14:59:08 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 317E644348; Mon, 8 May 2000 14:20:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E414844350 for ; Mon, 8 May 2000 14:19:51 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5E14852C4; Mon, 8 May 2000 14:19:44 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id D311D52C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20327 for ; Mon, 8 May 2000 08:08:02 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 08:00:31 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 08:00:30 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA119830 for ; Mon, 8 May 2000 21:55:23 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA46208 for ; Mon, 8 May 2000 22:00:22 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041F36F ; Mon, 8 May 2000 22:00:21 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:31 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Different Via grammar in the web Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, The Via grammar specified in the Columbia.edu's SIP page (http://www.cs.columbia.edu/sip/SIPgrammar.html#via) is different from the one in the draft. The difference is in the extension-params, i.e. the grammar in the web specifies that extension-params apply to the whole Via header, while the draft specifies that extension-params apply to each Via element. This is the one in the web page: Via = ( "Via" | "v") ":" 1#(sent-protocol sent-by *( ";" via-params ) [ comment ] ) *(";" extension-params) And this is the one in the draft: Via = ( "Via" | "v") ":" 1#(sent-protocol sent-by *( ";" via-params ) [ comment ] ) via-params = ... | via-extension Can anybody specify which one is correct? cheers, Bennylp _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:04:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15652 for ; Mon, 8 May 2000 15:04:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE27744354; Mon, 8 May 2000 14:54:16 -0400 (EDT) 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 1963344377 for ; Mon, 8 May 2000 14:53:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 14:59:08 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D36004435A; Mon, 8 May 2000 14:20:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 8912244348 for ; Mon, 8 May 2000 14:19:51 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0983D52D4; Mon, 8 May 2000 14:19:45 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 762FD52D2 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20305 for ; Mon, 8 May 2000 08:07:23 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:58:47 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:58:46 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA171164; Mon, 8 May 2000 21:53:39 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA42222; Mon, 8 May 2000 21:58:38 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041C7BE ; Mon, 8 May 2000 21:58:29 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:24 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: "headers" in SIP-URL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Shail Bhatnagar wrote: > > A look at the syntax of SIP-URL shows that headers can be defined in a SIP-URL > itself. However, the spec also says they MUST NOT be present in From/To and > Request-URI. Does it mean they can be present in Contact header (the addr-spec > portion of Contact) ?? > I don't see any good reason for headers being allowed inside a SIP-URL and I > would be curious to know how many implementations actually introduce it in > SIP-URL ( probably the Contact header) and rely on it. In a redirect, you can play tricks such as adding new headers to the next, redirected call. (For example, the redirect server could provide the password for another call.) While I doubt that it is used right now, it seems like a feature worth having around. > > Thanks, > > -- > Best regards, > Shail -- 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 May 8 15:14:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16015 for ; Mon, 8 May 2000 15:14:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DB2C4437B; Mon, 8 May 2000 15:08:04 -0400 (EDT) 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 B9B6A44345 for ; Mon, 8 May 2000 15:07:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:12:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6942D44360; Mon, 8 May 2000 14:20:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 2947544351 for ; Mon, 8 May 2000 14:19:51 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 80CA052D2; Mon, 8 May 2000 14:19:45 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id E825B52C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20444 for ; Mon, 8 May 2000 08:12:04 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 08:00:52 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 08:00:50 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA252622; Mon, 8 May 2000 21:55:43 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA48432; Mon, 8 May 2000 22:00:42 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041F933 ; Mon, 8 May 2000 22:00:36 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:32 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] TRIP for gateway registrations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Folks, Every once in a while, the question comes up of why SIP REGISTER is not the right vehicle for allowing gateways to register phone prefixes with a proxy. I believe TRIP is far better for this purpose. As it turns out, a small subset of TRIP is needed to solve this problem, and yet its still interoperable with full blown TRIP. Hussein Salama and I have written an I-D that discusses this. Until it appears in the archives, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 15:18:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16097 for ; Mon, 8 May 2000 15:18:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 33EAA44390; Mon, 8 May 2000 15:08:08 -0400 (EDT) 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 9DAA94435A for ; Mon, 8 May 2000 15:07:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:12:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 07E314434C; Mon, 8 May 2000 14:20:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id D47EE4435F for ; Mon, 8 May 2000 14:20:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1CAAA52D6; Mon, 8 May 2000 14:19:54 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id C43F452D4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20456 for ; Mon, 8 May 2000 08:12:37 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:59:27 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:59:25 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA215892; Mon, 8 May 2000 21:54:18 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA46154; Mon, 8 May 2000 21:59:17 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041D9C0 ; Mon, 8 May 2000 21:59:15 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "Igor Slepchin" Cc: "SIPbell-labs" Message-ID: Date: Mon, 8 May 2000 14:10:28 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: BYE and record route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Thanks for the pointers Igor. The documents really help. ----- Original Message ----- From: "Igor Slepchin" To: "Sunitha Kumar" Cc: "SIPbell-labs" Sent: Thursday, March 16, 2000 8:26 PM Subject: Re: BYE and record route > It certainly should, and not only for BYE requests. This is discussed in > http://www.cs.columbia.edu/~hgs/sip/notes.html (see the note on > Record-Route towards the end of the document) and in > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf > (section 6.3.33). > > --- > Igor Slepchin > > > Sunitha Kumar wrote: > > > > It is given that the record route in 200 OK is copied into the Route > > headers for subsequent requests from the caller. My question was, if > > we needed to make the BYE from the *callee* traverse the same set of > > proxies, then should this be rememberd from the INVITE request > > obtained from the caller, or does the via field help in that. > > > > Thanks! > > > > -- > > Sunitha Kumar > > Software Engineer > > Vovida Networks > > (408) 957 - 6374 > > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:21:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16205 for ; Mon, 8 May 2000 15:21:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A7A844345; Mon, 8 May 2000 15:08:17 -0400 (EDT) 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 E24614435D for ; Mon, 8 May 2000 15:07:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:12:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F02644435B; Mon, 8 May 2000 14:20:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 08CAA4434C for ; Mon, 8 May 2000 14:20:02 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B5A2352DB; Mon, 8 May 2000 14:19:47 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 3EA8552DC for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20125 for ; Mon, 8 May 2000 08:02:04 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:56:22 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:56:21 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA57428; Mon, 8 May 2000 21:50:55 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA15892; Mon, 8 May 2000 21:56:12 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00418DFD ; Mon, 8 May 2000 21:56:01 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:18 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] TRIP for gateway registrations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Folks, Every once in a while, the question comes up of why SIP REGISTER is not the right vehicle for allowing gateways to register phone prefixes with a proxy. I believe TRIP is far better for this purpose. As it turns out, a small subset of TRIP is needed to solve this problem, and yet its still interoperable with full blown TRIP. Hussein Salama and I have written an I-D that discusses this. Until it appears in the archives, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:24:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16258 for ; Mon, 8 May 2000 15:24:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 52C4B44396; Mon, 8 May 2000 15:08:24 -0400 (EDT) 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 2C7F64435E for ; Mon, 8 May 2000 15:07:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:12:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6991444349; Mon, 8 May 2000 14:20:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1749A4434F for ; Mon, 8 May 2000 14:20:07 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6EA3D52DF; Mon, 8 May 2000 14:19:54 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 043EB52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20179 for ; Mon, 8 May 2000 08:03:31 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 07:59:39 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:59:38 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA38296; Mon, 8 May 2000 21:54:13 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA51224; Mon, 8 May 2000 21:59:30 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041DC34 ; Mon, 8 May 2000 21:59:22 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Sunitha Kumar Cc: Igor Slepchin , SIPbell-labs Message-ID: Date: Mon, 8 May 2000 14:10:28 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: question in record-route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Sunitha Kumar wrote: > > Igor Slepchin wrote: > > > Sunitha Kumar wrote: > > > In record route, it is given that : if the response contained a > > > contact header field, the user agent adds its content as the last > > > route header. > > > > > > the question is; > > > > > > 1. after copying the content header field as the last record route > > > > > item, should the content header field be deleted? ( it doesn't > > make > > > sense otherwise) > > > > The UAC should never copy UAS's Contact in its own future requests > > regardless of whether Record-Route is present or not. > > So, then, is there some inconsistency in the RFC, that needs to be > addressed? No; the RFC never says to copy the Contact field from the response to subsequent requests. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 15:29:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16341 for ; Mon, 8 May 2000 15:29:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AE3024435D; Mon, 8 May 2000 15:08:31 -0400 (EDT) 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 71C934435F for ; Mon, 8 May 2000 15:07:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:12:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A839444363; Mon, 8 May 2000 14:20:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E328D44349 for ; Mon, 8 May 2000 14:20:04 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E1AF552AB; Mon, 8 May 2000 14:19:51 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id CF1D552E0 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20144 for ; Mon, 8 May 2000 08:02:48 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:58:07 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:58:06 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA122556; Mon, 8 May 2000 21:52:41 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA68372; Mon, 8 May 2000 21:57:58 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041BA9F ; Mon, 8 May 2000 21:57:56 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:23 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Why must a stateless proxy insert a Via header for itself. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Max-Forwards could be used to detect infinite loops. Alternatively, what if we implement another header called "ResponsePath" . If a proxy wants to be in the path of the response it will include itself there ( On the same lines of Route header which are used for being in path of future transactions). The Via header could be used for loop detection. Thanks, Anoop Shail Bhatnagar on 03/17/2000 11:48:17 AM Sent by: Shail Bhatnagar To: Anoop Tripathi/MW/US/3Com cc: sip@lists.research.bell-labs.com Subject: Re: Why must a stateless proxy insert a Via header for itself. Anoop Tripathi wrote: > > Currently, the RFC states that every server in the path of a request must add > itself as a Via header. > > As a stateless proxy, if this restriction is removed then I can process more > calls with faster call setup times. > > So , can we make inserting itself as a Via optional for a stateless proxy. > > Thanks, > > Anoop Then how do you do loop detection ?? -- Best regards, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:31:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16473 for ; Mon, 8 May 2000 15:31:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D38E94435E; Mon, 8 May 2000 15:08:38 -0400 (EDT) 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 B172544362 for ; Mon, 8 May 2000 15:07:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:12:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1E33B44351; Mon, 8 May 2000 14:20:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 97F9E44346 for ; Mon, 8 May 2000 14:20:02 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2B9BF52DA; Mon, 8 May 2000 14:19:47 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id B22BC52DB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20504 for ; Mon, 8 May 2000 08:13:52 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 08:00:00 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:59:58 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA73176; Mon, 8 May 2000 21:54:32 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA51232; Mon, 8 May 2000 21:59:48 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041E529 ; Mon, 8 May 2000 21:59:45 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:30 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] uploading services from the user's home network to a sip server of the visited network within a 3G.IP environement Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, after doing a very good job by deciding to take SIP for call control for multimedia services within 3G.IP networks, the 3G.IP operators have a lot of open items concerning the architecture, one of them being which network controls the services for a roaming user: the home network, the visited network or shared control. The concrete question: how can I upload at the begin or during the call the roamimg user's services available in the home network into the SIP proxy of the visited network? As far as I know, the CPL and REGISTER helps me to upload services only from the UA to the proxy. Is anyone else working on similar issues? I know of the Telcordia mobility efforts, but the 3G.IP requirements and architecture seem to be somehow different. The 3G.IP operators would like to reuse their just implemented GPRS and the GPRS mobility. Thanks a lot Laura _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:34:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16615 for ; Mon, 8 May 2000 15:34:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B7F1443BA; Mon, 8 May 2000 15:20:02 -0400 (EDT) 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 21B3C44391 for ; Mon, 8 May 2000 15:19:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:25:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 09AE044369; Mon, 8 May 2000 14:20:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 82CD44434D for ; Mon, 8 May 2000 14:20:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id BB86E52D4; Mon, 8 May 2000 14:19:56 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 4527F52E1 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20197 for ; Mon, 8 May 2000 08:04:04 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:58:00 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:57:59 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA122514 for ; Mon, 8 May 2000 21:52:34 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA68362 for ; Mon, 8 May 2000 21:57:51 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041B629 ; Mon, 8 May 2000 21:57:44 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Sip list Message-ID: Date: Mon, 8 May 2000 14:10:29 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Billing SIP proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Scott, Scott Bradner wrote: > > The question is: is it posible to define, to any extent, a mechanism > > capable of preventing the "hacked" terminal to bypass the proxy and call > > the "standard" endpoints witout being billed ? > > if they are not making any special use of the network (like QoS > reservations or fancy proxy services ) why should they be billed > in a way that is different than any other best-effort use of the > network? > Some telephony applications are currently heavily billed, at a rate much higher than the corresponding rate for pure best effort Internet access. In some domains, network operators hold a kind of oligopoly, thanks to government policies, that grant licencies only to a very restricted number of operators. Please don' t quote me on this, but I would say that there is no real competition between them, at least not harsh competition. At the moment, they are deciding wheter to continue with circuit switched networks or whethether to adopt IP-based networks. It is very likely that they make such a step *only* if they don' t see their revenues reduced (hopefully, they would like to increase them !) A model where best effort calls are free and QOS calls are billed will pobably apply in the future, but not in the short run, at least IMHO. Giuseppe _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:38:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16752 for ; Mon, 8 May 2000 15:38:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 584AC443B1; Mon, 8 May 2000 15:20:08 -0400 (EDT) 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 3B240443B4 for ; Mon, 8 May 2000 15:19:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:25:26 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 12CE74434F; Mon, 8 May 2000 14:20:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 36CB644355 for ; Mon, 8 May 2000 14:20:07 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 82EE052BB; Mon, 8 May 2000 14:19:55 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id BBE1A52E0 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20236 for ; Mon, 8 May 2000 08:05:20 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:57:56 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:57:54 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA47582; Mon, 8 May 2000 21:52:46 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA42502; Mon, 8 May 2000 21:57:45 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041B53D ; Mon, 8 May 2000 21:57:42 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Ken Carlberg Cc: "Rosen, Brian" , jmpolk@cisco.com, sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:27 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Ken Carlberg wrote: > > > On your final thread, it should certainly be possible to define > > an extension to SIP that is not useful in the PSTN; extensions > > that are useful only within an enterprise for example should > > be acceptable, or in the home, as well as something like MLPP > > which is useful within a government communications system. > > Agreed with respect to something that may or may not be "useful". But the > kicker that I'm curious about is whether the proposed specification is > illegal (not allowed) when applied to the general public. Here at IETF, we make protocols that run on the Internet, not the PSTN. As there are no regulations regarding this kind of thing on the Internet, it is not an issue for us. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 15:44:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16937 for ; Mon, 8 May 2000 15:44:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 206E4443CF; Mon, 8 May 2000 15:20:25 -0400 (EDT) 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 C56EF443B6 for ; Mon, 8 May 2000 15:19:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:25:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E35A444355; Mon, 8 May 2000 14:20:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 87C3C44365 for ; Mon, 8 May 2000 14:20:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5727552E6; Mon, 8 May 2000 14:20:01 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id B302652E7 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20216 for ; Mon, 8 May 2000 08:04:35 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:56:06 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:56:04 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA126664; Mon, 8 May 2000 21:50:54 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA46274; Mon, 8 May 2000 21:55:52 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00418648 ; Mon, 8 May 2000 21:55:42 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: James Yu Cc: "'Vance Shipley'" , John Mainwaring , Mark Foster , iptel@lists.research.bell-labs.com, sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:16 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: TRIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com We've discussed this on the list. Several folks pointed out that European systems support overlap, and it was decided that it was not reasonable to mandate the originating gateway to do digit collection to convert this to en-bloc, although it could be optionally done. -Jonathan R. James Yu wrote: > > Vance, > > Thanks for the explanation. > > The key questions now are whether overlap signaling (e.g., Feature Group-D > over Multi-Frequency facility) is still used somewhere and if used where the > digit collection/enbloc signaling is performed in the existing SCN. > > If overlap signaling is still used (someone please confirm this and indicate > where it is still used) and a call is to be routed from the originating SCN > to the Internet, I guess that the originating GW (SCN-Internet)probably has > to perform the digit collection/enbloc signaling function so that overlap > signaling does not propagate further into the Internet and/or the > destination GW/SCN. Otherwise, some entities in the Internet must perform > that function. > > James > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:47:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17042 for ; Mon, 8 May 2000 15:47:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C690443DB; Mon, 8 May 2000 15:28:01 -0400 (EDT) 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 7B38E443D9 for ; Mon, 8 May 2000 15:27:58 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id OAA05520; Mon, 8 May 2000 14:32:46 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA24450; Mon, 8 May 2000 14:32:43 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA26762; Mon, 8 May 2000 14:32:43 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id OAA06333; Mon, 8 May 2000 14:32:42 -0500 (CDT) Date: Mon, 8 May 2000 14:32:42 -0500 (CDT) Message-Id: <200005081932.OAA06333@b04a45.exu.ericsson.se> To: rworkman@nortelnetworks.com Subject: Re: [SIP] URI's in SIP messages Cc: sip@lists.bell-labs.com X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > The current SIP BNF allows the general form of URI (or URI-reference?) to > be used in the request line and various headers. Observations and > questions: > > 1. A valid form of URI (RFC 2396)is the empty sequence since: > > URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] > > This would permit the request line and various headers (To, From, > Contact. ..) without an address specification which doesn't seem to make > much sense. RFC 2396 specifies that the empty sequence URI refers to the > start of the current document; is there any corresponding abstraction for > SIP transcations? No. Please god no. Obviously RFC2396 specifies a much wider and more abstract form of URI than is commonly used in SIP. Not everything in 2396 is appropriate for every URI scheme. They are a set of guidelines that work more or less for the most common URI schemes in use today: http, ftp, telnet, mailto (with some quirks), etc. The Request-URI and Contact: URIs have different requirements for parsing than the To/From URIs. For example, a proxy can to a degree treat the To:/From: URIs as opaque strings but MUST understand the syntax/semantics of the Request-URI. This doesn't prevent you from doing rigorous parsing everywhere, but keep in mind that it doesn't necessarily need to be done everywhere. > > 2. The relative URI references a resource relative to a base URI of a > hierarchial scheme. So a similar question: is this a useful concept for > SIP sessions? > The only contexts where I would think this might be useful would be in 1) The headers parameter of a SIP URI (for the From: and possibly To: headers) 2) A SIP "cookie" similar to an HTTP-cookie. This hasn't really been investigated much but would be interesting. In other words, I don't think it is generally useful in the usual places in a SIP message (To/From/Contact/Request-URI). But it is potentially useful at the user interface level or as part of some service logic. > 3. Finally RFC 2396 states (my emphasis): > "When a URI reference is used to perform a retrieval action on the > identified resource, the optional fragment identifier, separated from > the URI by a crosshatch ("#") character, consists of additional > reference information to be interpreted by the user agent after the > retrieval action has been successfully completed. As such, it is not > part of a URI, but is often used in conjunction with a URI." > True, but this treated in very different ways by different web browsers. Some treat it as part of the URI, others use it for "post-processing". It's not really used in a standard way for SIP, but as stated above it really is up to the UserAgent's interpretation. THIS IS A GOOD THING. > > So this very general URI seems to have a number of properties which don't > seem to be relevant when used in place of a SIP URL. Since generality > often has a price either in implementation or specification, i.e., lots > of semantic constraints, does it make sense to restrict the syntactic > form of URI used in place of a SIP URL, e.g., to the absolute-URI form? > Well, if you really want to dig into this, the SIP URI as specified in 2543 is actually a much different beast. Technically the entire SIP URL according to 2396 falls under the "opaque_part" category of absolute URIs. What does this mean? It means that the syntax AND semantics of a SIP URI are NOT defined in 2396 at all but left to the definition in 2543. So from this perspective, much of 2396 does not apply to sip: URIs. I don't know if this was the intention of the SIP authors or not. From a common sense perspective, however, a SIP URI has all the properties of the URLs as defined in 2396: it is a transcribable uniform resouce identifier :) I see no benefit in restricting the syntax of a SIP URI. If you "ignore" the fact that the SIP URI should be treated as opaque, you can parse the SIP URI just like an http, ftp, telnet, etc. URI. In this sense, it would actually place more of a burden on an implementation to prescribe special syntax restrictions on a SIP URI. Furthermore, I'd prefer to leave open the possibility for future SIP extensions which might need something like a relative SIP URI. > > Rick Workman > Nortel Networks > Ottawa -- Sean Olson Ericsson Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:50:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17133 for ; Mon, 8 May 2000 15:50:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 387EC443F1; Mon, 8 May 2000 15:34:00 -0400 (EDT) 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 8A012443E9 for ; Mon, 8 May 2000 15:33:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 15:38:38 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 358FD44359; Mon, 8 May 2000 14:20:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C83F044368 for ; Mon, 8 May 2000 14:20:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8F23152DB; Mon, 8 May 2000 14:20:06 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id D0FCD52C4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20274 for ; Mon, 8 May 2000 08:06:16 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 08:01:07 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 08:01:06 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA206884; Mon, 8 May 2000 21:55:59 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA36272; Mon, 8 May 2000 22:00:59 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00420195 ; Mon, 8 May 2000 22:00:57 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Anders Kristensen Cc: "K. K. Ramakrishnan" , archow@hss.hns.com, sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:32 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Provisional Response Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Anders Kristensen wrote: > > "K. K. Ramakrishnan" wrote: > > > > I also appreciate the need to not have special casing for methods - > > but is this extra messaging coming about because we chose to > > have the PRACK as a "method"? On the issue of backwards compatibility, > > couldn't we say that proxies shouldn't be creating transaction state > > for things it doesn't understand? > > This proposal is itself not backwards compatible. Also, it doesn't seem > quite right - it would mean, for example, that proxies cannot fork on > requests they do not know. This seems like a big limitation. I agree completely here with Anders. The spec clearly defines handling for unknown requests as if they were BYE. As one of the design principles of SIP, we've really tried to make it a fairly general purpose protocol. Many of the features and capabilities have broad applicability and usage. Often, the result of this kind of a decision is a tradeoff- messages are a little bigger, or more information is sent, when its not always needed. I'd really like to keep with that design philosophy. Having special case methods to cover every new case, and requiring tons of Proxy-Requires to make it all work, ends up resulting in a tangled mess of a protocol that doesn't interoperate. Please, lets stick with the request-response model for all new methods. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 15:53:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17229 for ; Mon, 8 May 2000 15:53:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6CC85443E9; Mon, 8 May 2000 15:34:14 -0400 (EDT) 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 1A83D443EE for ; Mon, 8 May 2000 15:33:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:38:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 19FD444366; Mon, 8 May 2000 14:20:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 4E68644367 for ; Mon, 8 May 2000 14:20:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id F16BD52E7; Mon, 8 May 2000 14:20:02 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 7251252E8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20508 for ; Mon, 8 May 2000 08:14:04 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 08:00:00 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:59:57 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA33500; Mon, 8 May 2000 21:54:32 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA51234; Mon, 8 May 2000 21:59:49 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041E4C7 ; Mon, 8 May 2000 21:59:44 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "'Kundan Singh'" Cc: "'Dean Willis'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:29 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] RE: SIP & RTSP interworking? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I like this a lot better, but the problem I have is this, we'd like for BOTH sessions to be active at the same time and both of your proposals require a teardown of the SIP session. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 > -----Original Message----- > From: Kundan Singh [SMTP:kns10@cs.columbia.edu] > Sent: Wednesday, March 15, 2000 3:10 PM > To: Linden deCarmo > Cc: 'Dean Willis'; sip@lists.research.bell-labs.com > Subject: RE: SIP & RTSP interworking? > > -- > Kundan Singh http://www.cs.columbia.edu/~kns10 > > > This is an interesting suggestion, but the scenario I'm operating under > is > > this: > > > > UAC<->UAC (in this case the UAC really is an RTSP server), both must > > understand SIP and RTSP. I need a way to tie the sessions between two > > distinct protocols. Is a viable alternative to embed the RTSP SETUP > message > > as a SIP body for the INVITE? This would clearly associate the > sessions, > > but I hate to have a proprietary solution that wouldn't work with other > > products that understood SIP & RTSP. > > In that case, the UA may return the RTSP Contact: URI in (say) 3xx > response. > > UA1 UA2 > INVITE > --------------> > > 3xx Moved > Contact:rtsp://server/resource > <------------- > > SETUP rtsp://server/resource > --------------> > . . . > > Since UA here understand both SIP and RTSP it should not be > a problem. > > If the SIP call is already established, and UA2 wants to > switch to RTSP, then (IMO) it may use blind call transfer > (BYE,Also:rtsp://...) to ask UA1 to connect to RTSP > server of UA2. Comments ?? > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 15:56:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17334 for ; Mon, 8 May 2000 15:56:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DC524440E; Mon, 8 May 2000 15:46:05 -0400 (EDT) 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 DAC5D4440D for ; Mon, 8 May 2000 15:45:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:51:45 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E9DA644368; Mon, 8 May 2000 14:20:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 24ABE4436C for ; Mon, 8 May 2000 14:20:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 91A5652D4; Mon, 8 May 2000 14:20:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 2742C52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20117 for ; Mon, 8 May 2000 08:01:31 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 07:57:16 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:57:14 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA66694; Mon, 8 May 2000 21:51:47 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA52866; Mon, 8 May 2000 21:57:04 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041A39C ; Mon, 8 May 2000 21:56:57 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: hsalama@cisco.com Cc: "Mark D. Foster" , "'John Mainwaring'" , iptel@lists.research.bell-labs.com, "'James Yu'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:22 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: TRIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com "Hussein F. Salama" wrote: > > > In any case, determination of where the NPDB query is done is something > > I don't think is within the scope of iptel to determine. All we need to > > figure out is what kind of numbers are distributed in TRIP. Near as I > > can tell, since LRNs still refer to the prefix of numbers served by a > > switch, doing what we were doing all along works just fine. > > > > Yes what we're doing is OK, because the LRN is part of an office's > NPA-NXX prefix. But we may have to add a new field to the > ReachableRoutes attribute to mark a prefix as portable. A prefix is > marked as portable if at lease one number has been ported out of this > prefix. Hmm, why is that? Are you basically saying that if a prefix is marked as portable, an LS must do an LNP query before routing to numbers in that prefix? Then, if marked as not portable, there is no need for queries? If so, its an interesting idea. It solves the problem of N-1, which, from what I understand, was done in part because only carriers near the destination would need to install triggers to perform queries on numbers. However, if information on what prefixes are ported is distributed in TRIP, this information is effectively dynamically distributed. This means its equally easy for the query to be done at the first LS as the last. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 16:00:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17460 for ; Mon, 8 May 2000 16:00:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E787443B7; Mon, 8 May 2000 15:46:17 -0400 (EDT) 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 4F2D544410 for ; Mon, 8 May 2000 15:46:00 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:51:48 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8E13B44370; Mon, 8 May 2000 14:20:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 54CCA44365 for ; Mon, 8 May 2000 14:20:19 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D83F352D5; Mon, 8 May 2000 14:20:17 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id D5F3852BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20351 for ; Mon, 8 May 2000 08:08:17 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:58:59 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:58:57 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA51726; Mon, 8 May 2000 21:52:59 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA64686; Mon, 8 May 2000 21:58:15 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041C05E ; Mon, 8 May 2000 21:58:10 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com, ensc-tia@sfu.ca, sip-implementors@cs.columbia.edu, confctrl@isi.edu, iptel@lists.research.bell-labs.com, eriietf@kk.ericsson.se Message-ID: Date: Mon, 8 May 2000 14:10:23 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] SIP Bake-off - Registration Closed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hello! The registration for the 3rd SIP bakeoff is closed! The popularity of this event has by far exceeded expectations. Instead of having 15-17 teams as we expected, there are 33 teams now on the final list and nearly 100 people. Here is the final list of participating teams: Name Team Size Contact --------------------------------------- Nortel-1 5 orton@nortelnetworks.com Pingtel 2 dpetrie@pingtel.com Nortel-2 2 cjessen@nortelnetworks.com Mediatrix 2 etremblay@mediatrix.com Netspeak 2 noreilly@netspeak.com Telogy 1 wkwok@telogy.com Nuera 4 cteoh@nuera.com Catapult 4 terry@catapult.com Ericsson-2 3 hans@erix.ericsson.se Mitel 2 Ashok_Ganesan@Mitel.COM Agilent 2 douglas_carson@agilent.com Dynamicsoft 3 vpatel@dynamicsoft.com Broadsoft 4 joyce@broadsoft.com VTEL 2 rkrishna@vtel.com Delta 3 nurban@delta-info.com Radcom 2 mwinslow@radcomusa.com E*Club 2 jon2@andrew.cmu.edu 8x8 4 artru@8x8.com Helsinki Tech U. 2 jose@tct.hut.fi Columbia U. 3 hgs@cs.columbia.edu HP Labs 1 ak@hplb.hpl.hp.com Indigo 3 eb@indigo-software.com OZ.com 2 jii@oz.com Vovida 3 ldang@vovida.com Cisco 3 manojb@cisco.com IPCell 2 alex@ipcell.com FacetCorp 5 clark@facetcorp.com MCIW-3 4 kelvin.porter@wcom.com 3Com-1 2 Jerry_Mahler@mw.3com.com MCIW-1 3 mohammad.vakil@wcom.com Ericsson-1 3 adam.roach@ericsson.com 3Com-2 2 Ravandhu_hariram@3com.com MCIW-2 5 steven.r.donovan@wcom.com ----------------------------------------- TOTAL: 92 participants in 33 teams Have a nice thanksgiving everyone!! Regards, Ulf -- Ulf Andersson Ericsson Inc +1 972 583 7537 ulf.andersson@ericsson.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 16:03:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17672 for ; Mon, 8 May 2000 16:03:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9D86044410; Mon, 8 May 2000 15:46:31 -0400 (EDT) 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 D6C1B44412 for ; Mon, 8 May 2000 15:46:00 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:51:48 EDT 2000 Received: by lists.bell-labs.com (Postfix) id CF9C644379; Mon, 8 May 2000 14:20:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C73C344370 for ; Mon, 8 May 2000 14:20:16 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4B23B52D0; Mon, 8 May 2000 14:20:13 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 48EC752DF for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20493 for ; Mon, 8 May 2000 08:13:32 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Message-Id: <200005081213.IAA20493@chair.dnrc.bell-labs.com> Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 08:00:01 EDT 2000 Date: Mon, 8 May 2000 07:59:57 -0400 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:59:57 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA213028 for ; Mon, 8 May 2000 21:54:50 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA51236 for ; Mon, 8 May 2000 21:59:49 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041E473 ; Mon, 8 May 2000 21:59:43 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU Reply-To: Internet-Drafts@ietf.org To: _@research.bell-labs.com Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com au1.ibm.com; cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:30 +0530 Subject: I-D ACTION:draft-roach-sip-subscribe-notify-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Event Notification in SIP Author(s) : A. Roach Filename : draft-roach-sip-subscribe-notify-00.txt Pages : 8 Date : 07-Mar-00 This document describes an extension to the Session Initiation Protocol (SIP) [1] . The purpose of this extension is to provide a generic and extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occured. Concrete uses of the mechanism described in this document may be standardized in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.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-roach-sip-subscribe-notify-00.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-roach-sip-subscribe-notify-00.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. mailto:mailserv@ietf.org ftp://ftp.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 16:15:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18079 for ; Mon, 8 May 2000 16:15:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1BC0F44440; Mon, 8 May 2000 16:03:43 -0400 (EDT) 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 21ED644444 for ; Mon, 8 May 2000 15:59:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:04:56 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 4A7CF4436A; Mon, 8 May 2000 14:20:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 23D204437A for ; Mon, 8 May 2000 14:20:22 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 309B052BB; Mon, 8 May 2000 14:20:21 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 3994B52C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20378 for ; Mon, 8 May 2000 08:09:22 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:56:37 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:56:34 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA130696; Mon, 8 May 2000 21:51:25 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA68280; Mon, 8 May 2000 21:56:24 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041929B ; Mon, 8 May 2000 21:56:13 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com, Robert.Sparks@wcom.com Message-ID: Date: Mon, 8 May 2000 14:10:19 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Comments on transfer draft (sparks-sip-cc-transfer-00) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenberg wrote: > > > It would be really nice, however, to know ahead of time whether all > parties supported transfer (and any other mechanisms to be defined). The > Supported extension draft defines a way in which the UAC would indicate > to the UAS that it knows the new mechanism, but that draft does not > mandate that a UAS return a Supported header in the response to any > method (only OPTIONS). We can add this, and say that if a UAS receives a > request (with any method) with a Supported header, it should place a > Supported header in the response and list those features it knows. This > would allow a caller to know whether the called party supports transfer > before trying it. Thoughts? It might make sense to have both Allow and Supported in responses other than OPTIONS. In this case, Allow seems the more appropriate solution, given that it's a new method and that having two mechanisms to ask for the same thing seems a bad design. Thus, suggesting that final responses include Allow doesn't break anything (a UAC could have a simple logic that did "if response didn't have Allow, send an OPTIONS just in case"), but it does cut down on traffic. It's much nicer if the UAC can gray out a Transfer button rather than pop up a failure note after the caller has said "let me transfer you...". > The document says TRANSFER can't have a body. Why not? I can think of > some cool uses for this down the road. Why rule it out? If nothing else, one can always use it for "if you get dropped, here's the URL to click on to call me back...". > > The draft says: > > UA receiving a well-formed TRANSFER request SHOULD request approval > > from the user to proceed. In the absence of that request, or upon > > receiving approval from the user, the UA MUST submit an INVITE to > > the resource identified by the Transfer-To: header using the Call-ID > > from the TRANSFER request. > > This thing about the Call-ID being copied from the TRANSFER seemed odd. > Why is that? If you wanted to accomplish this, it seems better to have > the URL in the Transfer-To header contain the Call-ID as a URL > parameter. In other words, why not do: > > Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays Somehow, the recipient of the transfer request must know which call id this belongs to. It can either be a new call (when TRANSFER is really acting as a 'create call leg, please' request) or an existing call (standard transfer). Why create a new call-id if it relates to an existing call? -- 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 May 8 16:38:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18660 for ; Mon, 8 May 2000 16:38:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E676244495; Mon, 8 May 2000 16:27:42 -0400 (EDT) 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 2991C44497 for ; Mon, 8 May 2000 16:25:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:31:15 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D51104438E; Mon, 8 May 2000 14:21:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id A8E6644383 for ; Mon, 8 May 2000 14:21:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 764E052C4; Mon, 8 May 2000 14:21:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id A8DA752AB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA19945 for ; Mon, 8 May 2000 08:00:03 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:54:40 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:54:38 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA52994 for ; Mon, 8 May 2000 21:49:12 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA64594 for ; Mon, 8 May 2000 21:54:30 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00416987 ; Mon, 8 May 2000 21:54:28 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:15 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] SIP web site internship listings Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I know that a number of companies are interested in hiring summer interns for SIP-related topics. I also know there are some students looking for such opportunities. Since this mailing list is not really appropriate for such topics, I've started an informal list at http://www.cs.columbia.edu/sip. Comments, additions and suggestions (to me, not the list) are welcome. -- 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 May 8 16:55:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19354 for ; Mon, 8 May 2000 16:55:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4277B444CB; Mon, 8 May 2000 16:40:38 -0400 (EDT) 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 8748C44496 for ; Mon, 8 May 2000 16:39:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:44:24 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9E5FA44395; Mon, 8 May 2000 14:21:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7A31C44383 for ; Mon, 8 May 2000 14:21:14 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9386552C4; Mon, 8 May 2000 14:21:13 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id A351752AB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id HAA19852 for ; Mon, 8 May 2000 07:56:17 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:54:49 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:54:48 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA162266; Mon, 8 May 2000 21:49:41 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA48498; Mon, 8 May 2000 21:54:40 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00416AB2 ; Mon, 8 May 2000 21:54:31 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Rohan Mahy Cc: Anders Kristensen , kkrama@research.att.com, sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:15 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Provisional Response Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Rohan Mahy wrote: > > Hi, > > At 12:09 PM 3/9/00 , Jonathan Rosenberg wrote: > >All requests are responded to. period. > > I never debated this. The user agents will always have an opportunity to > respond. > > I agree with kkrama@research.att.com, that proxies shouldn't keep state for > methods they don't understand. They can simply forward messages for these > unknown methods on to the user agents or the next proxy. If you want to build your proxy that way, fine. But I think it is asking to much to mandate that unknown methods be forwarded statelessly. The spec as written does not mandate this. > So what I hear Jonathan saying is that because some proxies MIGHT keep > state for new methods, then we need 200 OK, so that we don't break them. > Correct? I am personally curious how many proxies would break. > > Also, I hear Jonathan saying that new methods should be processed in the > same way, and that this encourages simplicity. Aside from the comment > above, is there another motivation for this? Yes. It leads to a clean architectural implementation. It means I can build a base transaction mechanism that handles retransmissions and provisional responses and stuff without detailed message semantics, and then build semantic processing on top of this. It is this same motivation which has led me to conclude that transactions must be kept independent; so that, for example, if I send a BYE for an INVITE that hasn't been answered, the UAS should still answer the INVITE. The issue of allowing stateful proxies for unknown methods is a big one as well. It means that SIPs routing and searching capabilities can be reused for other services (i.e., other methods) with existing proxies. I think this is not to be dismissed so lightly. While there are clear advantages to keeping the 200 OK to PRACK, the only advantage I have heard to date for dropping it is message efficiency. In general, I firmly believe that generality and broad applicability are far more important design goals than message efficiency. I discuss this in more detail in the draft I recently submitted entitled "Guidelines for Authors of SIP Extensions". -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 17:22:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20064 for ; Mon, 8 May 2000 17:22:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B419A444FC; Mon, 8 May 2000 16:52:40 -0400 (EDT) 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 5FE1F444E1 for ; Mon, 8 May 2000 16:51:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:57:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 144D7443A3; Mon, 8 May 2000 14:21:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E84E4443A0 for ; Mon, 8 May 2000 14:21:25 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CBFAA52B6; Mon, 8 May 2000 14:21:24 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id BDEE852BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18567 for ; Mon, 8 May 2000 06:11:54 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:32 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:58:29 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAB114138 for ; Mon, 8 May 2000 19:53:22 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA14704 for ; Mon, 8 May 2000 19:58:21 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036C5FC ; Mon, 8 May 2000 19:58:16 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:06 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] New I-D available soon Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Folks, I've just posted an individual Internet Draft which may be of interest. Its entitled "Guidelines for Authors of SIP Extensions". Its discusses issues that writers of SIP extensions should consider while developing them and writing them up. It also gives some guidance on what things make good SIP extensions, and what things do not. Until it appears in the archives, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-guidelines-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 17:34:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20367 for ; Mon, 8 May 2000 17:34:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2565F44532; Mon, 8 May 2000 17:18:53 -0400 (EDT) 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 CB83D44533 for ; Mon, 8 May 2000 17:17:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:23:53 EDT 2000 Received: by lists.bell-labs.com (Postfix) id CE274443B3; Mon, 8 May 2000 14:21:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id A2DBF443AF for ; Mon, 8 May 2000 14:21:36 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E4DF352AB; Mon, 8 May 2000 14:21:35 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 049A652BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18575 for ; Mon, 8 May 2000 06:12:17 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:59:05 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:59:03 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA198270; Mon, 8 May 2000 19:53:27 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA28400; Mon, 8 May 2000 19:58:43 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036D006 ; Mon, 8 May 2000 19:58:41 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "Sip (E-mail)" , "ITU-T Study Group 16 (E-mail)" , "Sip-H323 (E-mail)" Message-ID: Date: Mon, 8 May 2000 14:10:08 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] FW: 47th IETF: SIP323 BOF Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com For those who may have missed it, here is the official announcement of the BOF. Dave Walker SS8 Networks Ottawa, Canada -----Original Message----- From: mbeaulie@cnri.reston.va.us [mailto:mbeaulie@cnri.reston.va.us]On Behalf Of ietf-secretariat@ietf.org Subject: 47th IETF: SIP323 BOF SIP and H.323 Interworking BOF (sip323) Monday, March 27 at 1300-1500 ============================= CHAIRS: Joon Maeng Dave Walker DESCRIPTION: There are two competing standards in the industry for establishing and managing real-time interactive media communications over IP. One is the proposed IETF standard, Session Initiation Protocol (RFC 2543), and the other is the ITU recommendation, H.323. Although they use the same protocol (RTP) for media streaming, they cannot establish calls between them. In the absence of any formal interoperability standards, many vendors are beginning to develop proprietary application gateways for interworking between SIP and H.323. In order to provide interoperability between the two standards, it is urgent to define a common interworking specifications for the industry. The recognition of the need for this interworking specification has lead to calls for its development from both manufacturers and service providers, individually and through industry consortia (such as IMTC) and other bodies concerned with interoperability (such as ETSI). In this BOF, we are going to discuss SIP and H.323 interworking issues, execution plans and the scope of the work. AGENDA: - Do we need SIP-H.323 interworking? - Coordination with other groups? - Scope of interworking - Outcome of the work? - Suggestions? Helpful reading: - draft-singh-sip-h323-00.txt - SIP: Session Initiation Protocol (RFC 2543) - SDP: Session Description Protocol (RFC 2327) - ITU recommendations: H.323, H.225.0, H.245 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 17:38:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20452 for ; Mon, 8 May 2000 17:38:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4749C4453F; Mon, 8 May 2000 17:18:11 -0400 (EDT) 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 2193844515 for ; Mon, 8 May 2000 17:05:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:10:46 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 4EB8E443B2; Mon, 8 May 2000 14:21:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id F358F443AF for ; Mon, 8 May 2000 14:21:35 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3695E52C8; Mon, 8 May 2000 14:21:35 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 721FE52AB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18347 for ; Mon, 8 May 2000 06:03:31 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 05:59:37 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:59:33 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA151386; Mon, 8 May 2000 19:54:25 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA72952; Mon, 8 May 2000 19:59:24 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036DDBA ; Mon, 8 May 2000 19:59:17 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Anders Kristensen Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:11 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Provisional Response Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Anders Kristensen wrote: > > > 2. Lets keep transactions independent. We went through a similar thing > > with CANCEL, and the state machines were confusing until we decided to > > make CANCEL a mini-transaction that does nothing but ask the UAS to > > quickly answer the request. I think we will see confusion in the PRACK > > processing if its operation becomes dependent on events in other > > transactions. > > It is certainly simpler to just always complete according to the > original plan, so to speak. Interestingly, though, one might have > thought it to be OK for the UAS to stop retransmitting reliable, > un-PRACK'ed responses when it sends a final response. The theory here > would be that this is so because either > 1) the reliable response has been lost before reaching the UAC, and so > there's no observable difference anywhere in the network from it never > having been sent, or > 2) the UAS did receive the reliable response so no retransmission are > needed anyway. > > The only snag I can see is that some proxy somewhere may in fact be > clever and act upon certain reliable responses, thus destroying > assumption 1) above, so it would appear to be prudent for the UAS to > retransmit as per the draft even in this case. Its not so much the proxy, as the UAC. If the UAS sent the response reliably, its probably because it contained some information that was important for the UAC to see. Otherwise, it wouldn't have sent it reliably in the first place. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 17:50:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20691 for ; Mon, 8 May 2000 17:50:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 342A544580; Mon, 8 May 2000 17:40:50 -0400 (EDT) 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 E901744564 for ; Mon, 8 May 2000 17:31:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:37:03 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 689A7443BF; Mon, 8 May 2000 14:21:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 234A8443AF for ; Mon, 8 May 2000 14:21:46 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5E7D352AB; Mon, 8 May 2000 14:21:45 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id C816C52C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18571 for ; Mon, 8 May 2000 06:12:05 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:41 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:58:39 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA132808; Mon, 8 May 2000 19:53:13 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA53148; Mon, 8 May 2000 19:58:30 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036CAE6 ; Mon, 8 May 2000 19:58:28 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Bryan Byerly Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:06 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Why do we need another header? Re: How to put a Kerberos ticket in SIP messages? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Before jumping into the syntax issues, I'd like to understand exactly whats going on here. Integration of Kerberos with SIP is a fairly big topic. There has been some discussion of this for establishing security associations between clients and local proxies as an alternative to IKE. You are proposing a different use yet, where it seems a redirect server is acting as a KDC, handing out tickets in SIP redirects. Lots of issues here, syntax is the least interesting one, IMHO. How is the client authenticating itself to the redirect/KDC in the first place? Does a client cache tickets and try to use them later when connecting to a server it was redirected to previously? What if the server thats redirected to, with a ticket, is yet another redirect server? I'm not saying I don't like this idea (in fact, I think its a very interesting one indeed), but I'd rather discuss higher level issues first. Actually, I'd love to see an I-D first to give a context for the discussion. -Jonathan R. Bryan Byerly wrote: > > So I expect a few people to come back and ask why not reuse an existing > header. > > I'm trying to achieve a flow where a SIP proxy hands back a Kerberos > ticket to a client. The client, in turn can use this ticket for > authorization to receive a service. (Yes, alternatively the client could > go get his own ticket (if he knew the IP address of the KDC and was an > authorized Kerberos client), and this follows along with moving complexity > out to the endpoints. However, I'm trying to initially simplify things > for dumber, less complex SIP clients. (and yes, I agree that SIP clients > could eventually go get their own tickets)). > > Let's go through the list of existing headers and why we can't use them: > > 401 WWW-Authenticate: header and Authorization: header > Using 401's WWW-Authenticate: header and the Authorization: header are > used for end-to-end authorization. So, using WWW-Authenticate is not > appropriate for passing back a Kerberos ticket. > > 407's Proxy-Authenticate: header and Proxy-Authorization: header > Using 407's Proxy-Authenticate: header and the Proxy-Authorization: header > are used to authorize a SIP client to transit through a SIP proxy. > Proxy-Authorization: is specified by a SIP client to provide credentials > such that he will be authorized by the SIP proxy. So, I don't think its > appropriate to overload Proxy-Authorization: to mean "here's an > authorization that the SIP proxy is passing to the SIP client". > > Response-Key: > This header is used by a client to specify a key which it requests the > called user agent should use to encrypt a response. So, its not > appropriate to use this header to pass a ticket. > > Thanks again for your help and suggestions! > > Bryan > > Bryan J. Byerly > byerly@cisco.com > > Bryan Byerly wrote: > > > Hi guys, > > > > I'm trying to understand how best to place a Kerberos (v5) ticket in > > SIP messages (i.e. either in SIP request or SIP response). > > (If someone already has such as draft, please forward me a copy.) > > > > I can think of two possible approaches: > > 1) Put it in a SIP header: > > 2) Put it in the SDP > > other ideas? > > > > 1) Thoughts on putting it in a header > > So, a Kerberos ticket is ASN.1 DER encoded. Is there any reason we > > couldn't just stick the binary representation of the ASN.1 DER encoded > > object in a header? > > Something like: > > ticket=fj7d543ghklc8654f7... > > (Yes, you're right, that's not a real ticket). > > > > So, I'm leaning towards a more generic header name like: > > Service-Authorization=[service name], [authorization-type], > > encoding=[encoding-type], ticket={octet string} > > authorization-type=kerberos5 > > encoding=octet-string > > > > b) Thoughts on putting it in the SDP > > > > Since a Kerberos ticket is ASN.1 DER encoded, it occurs to me that we'd > > need a email-safe version of the Kerberos ticket if we were to place it > > in the SDP. > > > > Can anyone point me to an existing draft/rfc which converts a Kerberos > > key to an email-safe version. I guess a draft on converting an > > arbitrary octet-string to an email-safe version would be fine too. > > > > P.S. > > For fun, who has a suggestion for which SDP abbreviation should be used > > for a Kerberos ticket? (It appears all the obvious ones are taken). > > taken: a, b, c, e, i, k, m, o, p, r, s, t, u, v, z > > remaining: f, g, h, j, l, n, q, w, x, y (Please correct me if some > > of these is already taken). > > > > Thanks for your help! > > > > Bryan > > > > Bryan J. Byerly > > byerly@cisco.com -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 18:00:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20890 for ; Mon, 8 May 2000 18:00:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8FF444596; Mon, 8 May 2000 17:46:19 -0400 (EDT) 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 DD0D94459B for ; Mon, 8 May 2000 17:45:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:50:15 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 505E144348; Mon, 8 May 2000 15:09:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 25F1C44341 for ; Mon, 8 May 2000 15:09:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D0F2252B6; Mon, 8 May 2000 15:09:06 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 00B0A52AB for ; Mon, 8 May 2000 15:09:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 15:08:41 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon May 8 15:08:40 EDT 2000 Received: from dynamicsoft.com (1Cust5.tnt3.freehold.nj.da.uu.net [63.25.172.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA02382; Mon, 8 May 2000 15:09:44 -0400 (EDT) Message-ID: <39171342.C46A159B@dynamicsoft.com> Date: Mon, 08 May 2000 15:19:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ozsip@oz.com Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Content-Language header References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit What you are describing is actually something different still. Accept-Language describes the language that may be used for the content in a response. This has nothing to do with the language an operator you might be connected to is able to speak; for that, the caller preferences extension is targeted (in fact, it has preferences for languages spoken). This is also different from Content-Language, which describes the language of the html or text in a SIP response. As Henning has pointed out, the only real use for this is some kind of automated translation systems. I know its optional and not hard, but I would rather not add more stuff to an ever-more-complex protocol unless there is a very well defined need. Since there is realistically no useful application right now of Content-Language, I'd rather not add it. -Jonathan R. ozsip@oz.com wrote: > > > Realistically, what are the applications for Content-Language? What > > would a client do differently on receiving a Spanish version vs. > > English? I see the value in Accept-Language, so that I get the right > > thing back in the first place, but Content-Language? > > Perhaps if you would send a SIP invitation with "Content-Language: Spanish" > to sip:support@somewhere.com, you would prefer the proxy at somewhere.com > to route your call to a support representative who spoke spanish. > > -David H. Brandt > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 18:10:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21123 for ; Mon, 8 May 2000 18:10:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C7B2445BA; Mon, 8 May 2000 17:58:13 -0400 (EDT) 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 2963844597 for ; Mon, 8 May 2000 17:57:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 18:03:24 EDT 2000 Received: by lists.bell-labs.com (Postfix) id EB3A04434C; Mon, 8 May 2000 17:27:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id B9E2944341 for ; Mon, 8 May 2000 17:27:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 426C652C4; Mon, 8 May 2000 17:27:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F110652B6 for ; Mon, 8 May 2000 17:27:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 17:26:48 EDT 2000 Received: from bounty.cisco.com ([161.44.3.204]) by dusty; Mon May 8 17:26:47 EDT 2000 Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id RAA03970; Mon, 8 May 2000 17:26:11 -0400 (EDT) Message-ID: <391730F3.65CB61DF@cisco.com> Date: Mon, 08 May 2000 17:26:11 -0400 From: Manoj Bhatia Organization: Cisco Systems, RTP, NC, USA. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: archow@hss.hns.com, "Adam B. Roach" , sip@lists.research.bell-labs.com, stlevy@cisco.com References: <6525689E.0030D6CF.00@sampark.hss.hns.com> <38CF11A4.F04178D4@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------C7B188F4B318E3013FA2FCE1" Subject: [SIP] Re: Two New Drafts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------C7B188F4B318E3013FA2FCE1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan Can we at least draw some consensus on the 'Meesage Waiting Indication(MWI)' event in Voice mail context ? Further, in one of the threads on this list, Henning says that we must adopt drafts/discussion on PINT to decide on MWI. Also, there is some concern that whether SUBSCRIBE - a new SIP method should be used for sending subscription requests or is REGISTER a good way of doing that ? My concern is that very soon you may have interop problems with SUBSCRIBE/ REGISTER method being used by vendors in different ways . Is SUBSCRIBE/NOTIFY the de facto way for MWI implementation ? Is a voice mail server supposed to act as a UA keeping track of dynamic subscription requests all the time and updating its database on time or should it depend on the proxy /registrar to take the burden of MWI by using the Contact/Registration details of the UA ? Comments welcome... thanks -manoj Jonathan Rosenberg wrote: > I think we are once again jumping the gun a bit. There are some much > bigger issues to address with a generic sip subscription/notification > mechanism: > > 1. what entities are generating the notifications? It can be a UA, or it > could be a proxy or registrar. > > 2. What are the types of events we want to support subscriptions for? I > know Adam has tried to keep that the subject of future extensions. > Problem is, this issue has a strong impact on the addressing, event > description and scaling capabilities. I don't think we can leave this to > future extensions without having the "base" version have nothing but two > methods. That doesn't really help much. I think we can define reasonably > broad classes of events. Certainly we aren't interested in supporting > events like "let me know when the coffee machine is done". > > 3. To whom does one address a subscription? If we address it to a user, > what does that mean? Are we asking for a subscription to that users > registration state? > > Also, before we get to far with architecture and design issues, there is > the question about whether this concept, in general, is something the > working group is interested in pursuing. > > -Jonathan R. > > archow@hss.hns.com wrote: > > > > Hi, > > responses embedded and preceded by ARC> > > > > >The draft does not mention what happens when multiple SUBSCRIBE requests > > >arrive from the same user. In REGISTER, > > > they replace old ones if the SIP url is same and additive otherwise. > > >However, in SUBSCRIBE, I think it would make sense to make it additive > > >only, since the same SIP url can subscribe to multiple events using diff. > > >subscription messages. Is this correct ? > > > > That sounds good, except possibly for the same "call leg". I think the > > part that needs to be clarified is: if a user sends a SUBSCRIBE > > which has the same Call-ID, From, and To as a previous request, > > does it add events or override them? I'm leaning towards overrriding > > events, since there is no easy way to remove events otherwise. Note well > > that this wouldn't apply to other subscriptions with different Call-IDs, > > which would (of course) remain additive. > > > > ARC> Somehow, I feel Call-ID and suscription should not be tied together. > > This is primarily > > ARC> because callid is generated by a terminal and a user has no control > > over it. > > ARC> However, a subscription is for a user, not a terminal. so if I > > subscribe to a set of services > > ARC> today, if I travel tomorrow, I want to walk into a Cyber Cafe, log in > > using some applet based > > ARC> sip client that will generate a different Call-ID from my old desktop > > one an still be able to > > ARC> access my old subscription list and add/del from it without having to > > know the Call-Id - which > > ARC> in many cases, I never get to see as a user. > > ARC> but the moment the backend notifier works on Call-ID - then I would > > never be able to 'Add' to > > ARC> my list since Ill be using a different Call-ID in all probability, > > neither will I be able to > > ARC> somehow retrieve the old one, since match will never be true. > > ARC> This is why I feel subscription should not be linked to a call - id. > > > > (Incidentally, I like your example. I have recently had > > discussions with several different groups of people who > > wanted to know how one would go about, for example, having > > a light blink on your phone and/or have a distinctive dial > > tone when a message is waiting). > > > > ARC> Well, we actually had exactly the above requirement once, and we did > > it my adding > > ARC> an Event like field with more or less the same semantics as we > > discussed above. > > > > >Event = 1#(eventid ; duration) > > >event = token // Does it need to be broken ? > > >duration = deltaseconds | SIP-Date > > > > I don't really like this. Beyond the problems with using > > commas for separators *and* having commas appear in > > the duration (if the SIP-Date format is used), I'm trying to > > keep it as congruent as possible with REGISTER, since the > > semantics for that are already well defined -- and code is > > already written to handle it. For the above situation, I'd > > propose that you either: a) send all three REGISTER messages, > > with different Call-IDs, in a single UDP packet, or b) send > > a single REGISTER for all three events with an expires of 2 > > hours. At the end of the 2 hours, re-SUBSCRIBE for just B > > and C (expires in one hour), and one hour later, re-SUBSCRIBE > > for just C. (A variation on this theme would be to subscribe > > for 4 hours, override it in 2, and then again one hour later; > > I prefer this method, since it eliminates the chances of missing > > events -- although it counts on the addition vs. replacement > > semantics I describe above). > > > > ARC> I assume where ever you mentioned REGISTER above , you meant SUBSCRIBE > > ARC> Again, solution 1 is to me, a kind of loose workaround. And the other > > solutions > > ARC> force the client to maintain time differentiators actively since it > > must physically > > ARC> maniuplate subscriptions to implement the common requirement above. > > Rather, The > > ARC> Notifier is actually already implementing a timer list which can > > notify users > > ARC> based on differential time values maybe, so why force the client into > > maintain the > > ARC> differential list also ? To me it seems to be much cleaner for the > > client to specify > > ARC> it once, and forget about it, as the notifier server is there just to > > remind him anyway > > ARC> so why bog him down with keeping track of such requests ? > > ARC> The only -ve point seems to be parsing for commas (which is a non > > issue for good parsers) > > ARC> - but if that really is a problem, maybe we could work at a simpler > > expiry type ? > > ARC> However, I dont feel parsing should be the reason to adopt the > > alternate methods suggested > > ARC> above. What do you/others feel abt it ? > > > > I must have been somewhat unclear. I am not proposing that one > > use REGISTER itself to cancel a subscription; merely that one > > use the same *mechanism*, with a SUBSCRIBE method. For > > example, let's say that I want to cancel the subscription(s) > > above. I could do so by sending: > > > > ARC> Sorry, I misinterpreted, then. Seems fine to me. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, P.O. Box 14987 | :|||||: :|||||: Research Triangle Park, NC 27709 | .:|||||||:.:|||||||:. 919-392-3873 fax: 919-392-6801 | C i s c o S y s t e m s --------------C7B188F4B318E3013FA2FCE1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan

Can we at least draw some consensus on the 'Meesage Waiting Indication(MWI)'
event in Voice mail context ?

Further, in one of the threads on this list, Henning says that we must adopt
drafts/discussion on PINT to decide on MWI.

Also, there is some concern that whether SUBSCRIBE -  a new SIP method
should be used for sending subscription requests or is REGISTER a good way of doing that ?

My concern is that very soon you may have interop problems with SUBSCRIBE/
REGISTER method being used by vendors in different ways .

Is SUBSCRIBE/NOTIFY the de facto way for MWI implementation ?

Is a voice mail server supposed to act as  a UA keeping track of dynamic
subscription requests all the time and updating its database on time
or should it depend on the proxy /registrar to take the burden of MWI
by using the Contact/Registration details of the UA ?

Comments welcome...

thanks
-manoj
 
 

Jonathan Rosenberg wrote:

I think we are once again jumping the gun a bit. There are some much
bigger issues to address with a generic sip subscription/notification
mechanism:

1. what entities are generating the notifications? It can be a UA, or it
could be a proxy or registrar.

2. What are the types of events we want to support subscriptions for? I
know Adam has tried to keep that the subject of future extensions.
Problem is, this issue has a strong impact on the addressing, event
description and scaling capabilities. I don't think we can leave this to
future extensions without having the "base" version have nothing but two
methods. That doesn't really help much. I think we can define reasonably
broad classes of events. Certainly we aren't interested in supporting
events like "let me know when the coffee machine is done".

3. To whom does one address a subscription? If we address it to a user,
what does that mean? Are we asking for a subscription to that users
registration state?

Also, before we get to far with architecture and design issues, there is
the question about whether this concept, in general, is something the
working group is interested in pursuing.

-Jonathan R.

archow@hss.hns.com wrote:
>
> Hi,
> responses embedded and preceded by ARC>
>
> >The draft does not mention what happens when multiple SUBSCRIBE requests
> >arrive from the same user. In REGISTER,
> >     they replace old ones if the SIP url is same and additive otherwise.
> >However, in SUBSCRIBE, I think it would make sense to make it additive
> >only, since the same SIP url can subscribe to multiple events using  diff.
> >subscription messages. Is this correct ?
>
> That sounds good, except possibly for the same "call leg". I think the
> part that needs to be clarified is: if a user sends a SUBSCRIBE
> which has the same Call-ID, From, and To as a previous request,
> does it add events or override them?  I'm leaning towards overrriding
> events, since there is no easy way to remove events otherwise. Note well
> that this wouldn't apply to other subscriptions with different Call-IDs,
> which would (of course) remain additive.
>
> ARC> Somehow, I feel Call-ID and suscription should not be tied together.
> This is primarily
> ARC> because callid is generated by a terminal and a user has no control
> over it.
> ARC> However, a subscription is for a user, not a terminal. so if I
> subscribe to a set of services
> ARC> today, if I travel tomorrow, I want to walk into a Cyber Cafe, log in
> using some applet based
> ARC> sip client that will generate a different Call-ID from my old desktop
> one an still be able to
> ARC> access my old subscription list and add/del from it without having to
> know the Call-Id - which
> ARC> in many cases, I never get to see as a user.
> ARC> but the moment the backend notifier works on Call-ID - then I would
> never be able to 'Add' to
> ARC> my list since Ill be using a different Call-ID in all probability,
> neither will I be able to
> ARC> somehow retrieve the old one, since match will never be true.
> ARC> This is why I feel subscription should not be linked to a call - id.
>
> (Incidentally, I like your example. I have recently had
> discussions with several different groups of people who
> wanted to know how one would go about, for example, having
> a light blink on your phone and/or have a distinctive dial
> tone when a message is waiting).
>
> ARC> Well, we actually had exactly the above requirement once, and we did
> it my adding
> ARC> an Event like field with more or less the same semantics as we
> discussed above.
>
> >Event =  1#(eventid ; duration)
> >event = token       // Does it need to be broken ?
> >duration = deltaseconds | SIP-Date
>
> I don't really like this. Beyond the problems with using
> commas for separators *and* having commas appear in
> the duration (if the SIP-Date format is used), I'm trying to
> keep it as congruent as possible with REGISTER, since the
> semantics for that are already well defined -- and code is
> already written to handle it.  For the above situation, I'd
> propose that you either: a) send all three REGISTER messages,
> with different Call-IDs, in a single UDP packet, or b) send
> a single REGISTER for all three events with an expires of 2
> hours. At the end of the 2 hours, re-SUBSCRIBE for just B
> and C (expires in one hour), and one hour later, re-SUBSCRIBE
> for just C. (A variation on this theme would be to subscribe
> for 4 hours, override it in 2, and then again one hour later;
> I prefer this method, since it eliminates the chances of missing
> events -- although it counts on the addition vs. replacement
> semantics I describe above).
>
> ARC> I assume where ever you mentioned REGISTER above , you meant SUBSCRIBE
> ARC> Again, solution 1 is to me, a kind of loose workaround. And the other
> solutions
> ARC> force the client to maintain time differentiators actively since it
> must physically
> ARC> maniuplate subscriptions to implement the common requirement above.
> Rather, The
> ARC> Notifier is actually already implementing a timer list which can
> notify users
> ARC> based on differential time values maybe, so why force the client into
> maintain the
> ARC> differential list also ? To me it seems to be much cleaner for the
> client to specify
> ARC> it once, and forget about it, as the notifier server is there just to
> remind him anyway
> ARC> so why bog him down with keeping track of such requests ?
> ARC> The only -ve point seems to be parsing for commas (which is a non
> issue for good parsers)
> ARC> - but if that really is a problem, maybe we could work at a simpler
> expiry type ?
> ARC> However, I dont feel parsing should be the reason to adopt the
> alternate methods suggested
> ARC> above. What do you/others feel abt it ?
>
> I must have been somewhat unclear. I am not proposing that one
> use REGISTER itself to cancel a subscription; merely that one
> use the same *mechanism*, with a SUBSCRIBE method. For
> example, let's say that I want to cancel the subscription(s)
> above. I could do so by sending:
>
> ARC> Sorry, I misinterpreted, then. Seems fine to me.

--
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, P.O. Box 14987    |     :|||||:   :|||||:
Research Triangle Park, NC 27709       |   .:|||||||:.:|||||||:.
919-392-3873      fax: 919-392-6801    |  C i s c o S y s t e m s
  --------------C7B188F4B318E3013FA2FCE1-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 18:15:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21216 for ; Mon, 8 May 2000 18:15:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7E4844391; Mon, 8 May 2000 15:20:15 -0400 (EDT) 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 7C384443B5 for ; Mon, 8 May 2000 15:19:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:25:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 511624436D; Mon, 8 May 2000 14:20:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7491944362 for ; Mon, 8 May 2000 14:20:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id AC2D552E4; Mon, 8 May 2000 14:19:59 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 4010152E5 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20244 for ; Mon, 8 May 2000 08:05:31 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 07:58:26 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:58:25 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA241176; Mon, 8 May 2000 21:53:00 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA64688; Mon, 8 May 2000 21:58:17 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041BEA3 ; Mon, 8 May 2000 21:58:06 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Sunitha Kumar Cc: SIPbell-labs Message-ID: Date: Mon, 8 May 2000 14:10:23 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Query on matching requests to responses at the proxies Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Sunitha Kumar wrote: > > How do we match requests to responses at the proxies.( other than the > branch in the Via); > using preferably the fields in a CallLeg, ( so that the call can be > uniquely identified). > > Ex: responses to 2 INVITES > Is it legal for the proxy to tag the from field of every request that > it forwards or proxies on, and remove the From tag, when the response > to that comes back, before passing it downstream. Making sure, that > each proxy on the way, adds itself to the record route. So, they are > traversed on the way back. Why do this? You'll break authentication and it won't work if a tag was already there. > > on other thoughts, what about incrementing the CSeq for every request > that goes out, and decrementing the CSeq , when the response for that > arrives, before passing it downstream. I also highly recommend against this. If the client sends a request with that same CSeq, which does not pass through your proxy somehow, things will be mightily confused. Also this doesn't work with authentication. Why do you want to do this? The spec is quite clear on how responses are matched to requests. Why does incrementing the CSeq help in any way? -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 19:48:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23128 for ; Mon, 8 May 2000 19:48:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 42341443A8; Mon, 8 May 2000 16:03:21 -0400 (EDT) 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 4F9B74443E for ; Mon, 8 May 2000 15:59:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:04:57 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 39C7F4437A; Mon, 8 May 2000 14:20:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 065AE44365 for ; Mon, 8 May 2000 14:20:24 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C7F1A52AB; Mon, 8 May 2000 14:20:22 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id AAB4052C4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20232 for ; Mon, 8 May 2000 08:05:18 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 07:58:36 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:58:34 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA173104; Mon, 8 May 2000 21:53:27 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA31402; Mon, 8 May 2000 21:58:26 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041C3F3 ; Mon, 8 May 2000 21:58:20 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Steve Little Cc: SIP Mailing List Message-ID: Date: Mon, 8 May 2000 14:10:24 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Steve Little wrote: > > Hi all, > This Q is wrt construction of Route header by called > EP. (6.32.3, bis) > It mentions that while sending future requests, the > called EP copies the Record-Route entries into is > Route header preserving order. > > So, If say from A(Calling)->B(Called), a request > from A took path A-P1-P2-P3-B, ie > Record-Route: P3, P2, P1 > Then when B sends a BYE, it copies the Rec-Route as > Route: P3, P2, P1, A > > Above makes sense. But what I dont understand is the > statement that URIs contaned in Rec-Route are not > useful in reverse path. Thats because these URIs all refer to addresses for B, not for A. Remember, the Record-Route header is built by copying the request URI of the request as it goes from A to B. So, lets be specific about your example: B is actually userB@company.com. So, A sends an INVITE like this: INVITE sip:userB@company.com SIP/2.0 Contact: sip:userA@university.edu .... to its local proxy P1. P1 looks up company.com (P2) and forwards it there, and adds itself to the Record-Route. The forwarded request looks like: INVITE sip:userB@company.com SIP/2.0 Contact: sip:userA@university.edu Record-Route: sip:userB@company.com;maddr= Now, company.com (P2) checks for userB in its database, and finds that this is Joe.B@sales.company.com. So, it adds itself to the Record-Route and forwards the request to sales.company.com (P3): INVITE sip:Joe.B@sales.company.com SIP/2.0 Contact: sip:userA@university.ede Record-Route: sip:userB@company.com;maddr= Record-Route: sip:userB@company.com;maddr= Now, P3 (sales.company.com) knows where Joe is right now because of registrations. Its sip:Joe.B@host3.sales.company.com. So, it adds itself to the record-route and forwards it there: INVITE sip:Joe.B@host3.sales.company.com SIP/2.0 Contact: sip:userA@university.ede Record-Route: sip:Joe.B@sales.company.com;maddr= Record-Route: sip:userB@company.com;maddr= Record-Route: sip:userB@company.com;maddr= now, it arrives at B (Joe.B@host3.sales.company.com), and the call is up. Now, Joe wants to send that BYE to hang up. If, as you suggest, it constructs the Route header with the same URI, the request it sends will to P3 look like: BYE sip:Joe.B@sales.company.com SIP/2.0 Route: sip:userB@company.com;maddr= Route: sip:userB@company.com;maddr= Route: sip:userA@university.edu Note that the request URI of this request is actually B, not A. This request above will actually be routed correctly, so long as (1) every proxy obeys the route headers, (2) every proxy uses the maddr parameter. If any proxy messes either up, the request is probably going to loop back to B. Thats bad. Thus, the mechanism is brittle. By having the called party construct the BYE in the following way: BYE sip:userA@university.edu SIP/2.0 Route: sip:userA@university.edu;maddr= Route: sip:userA@university.edu;maddr= Route: sip:userA@university.edu We guarantee things work right, even if any proxy ignores the Routes or ignores maddr. The request is still routed correctly. Thats why its done this way. We wish to preserve the rule that the request URI indicates where the request is going. > In the above example, am I not re-using the URLs in > the record-route for the reverse path ? > Also, Im not clear what the statement > "However, all components except the maddr parameter > are replaced by the calling URI." means - calling URI > replaces what ? the Route list ? I guess not. I think the example clarifies this. Only the maddr parameter from the Record-Route header is used when the UAS constructs the Route header. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 19:53:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23210 for ; Mon, 8 May 2000 19:53:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2033F4456B; Mon, 8 May 2000 17:40:27 -0400 (EDT) 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 05921443C7 for ; Mon, 8 May 2000 17:31:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 17:37:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 57E46443C4; Mon, 8 May 2000 14:21:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 118F0443C2 for ; Mon, 8 May 2000 14:21:49 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7495F52AB; Mon, 8 May 2000 14:21:48 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 5A0C052C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18396 for ; Mon, 8 May 2000 06:05:35 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:59:19 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:59:11 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA182032; Mon, 8 May 2000 19:54:03 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA45746; Mon, 8 May 2000 19:58:58 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036D400 ; Mon, 8 May 2000 19:58:52 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:09 +0530 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=MxOdF2ZYnZL1QmzJNFii2izWWQGKJiP6THgwh8QrcuTNr9Vg8dbQSa4Q" Content-Disposition: inline Subject: [SIP] RE: TRIP for gateway registrations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --0__=MxOdF2ZYnZL1QmzJNFii2izWWQGKJiP6THgwh8QrcuTNr9Vg8dbQSa4Q Content-type: text/plain; charset=us-ascii Content-Disposition: inline I would point out that H.323 RAS messages are not normally used to register a range of phone numbers for gateways as it is quite impractical, especially for gateways handling a large number of phone numbers, and when keep-alive messages are used. While some implementations uses tricks such as registering "dialling prefixes" to map to telephone number, it is not the intent of prefixes which are supposed to be used for special services. Normally, a gateway registers an alias with its gatekeeper and the binding between the alias and the range of phone numbers handled by the gateway is "manually" configured in the gatekeeper, as described in the draft. I would think that TRIP could automate this process. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, March 09, 2000 11:33 PM > To: sip@lists.research.bell-labs.com; > iptel@lists.research.bell-labs.com > Subject: TRIP for gateway registrations > > > Folks, > > Every once in a while, the question comes up of why SIP > REGISTER is not > the right vehicle for allowing gateways to register phone > prefixes with > a proxy. I believe TRIP is far better for this purpose. As it > turns out, > a small subset of TRIP is needed to solve this problem, and yet its > still interoperable with full blown TRIP. Hussein Salama and I have > written an I-D that discusses this. Until it appears in the archives, > you can pick up a copy at: > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > --0__=MxOdF2ZYnZL1QmzJNFii2izWWQGKJiP6THgwh8QrcuTNr9Vg8dbQSa4Q Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1MS42NSI+DQo8VElUTEU+UkU6IFRS SVAgZm9yIGdhdGV3YXkgcmVnaXN0cmF0aW9uczwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0K PFA+PEZPTlQgU0laRT0yPkkgd291bGQgcG9pbnQgb3V0IHRoYXQgSC4zMjMgUkFTIG1lc3NhZ2Vz IGFyZSBub3Qgbm9ybWFsbHkgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj51c2VkIHRvIHJlZ2lz dGVyIGEgcmFuZ2Ugb2YgcGhvbmUgbnVtYmVycyBmb3IgZ2F0ZXdheXMgYXMgaXQgPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5pcyBxdWl0ZSBpbXByYWN0aWNhbCwgZXNwZWNpYWxseSBmb3IgZ2F0 ZXdheXMgaGFuZGxpbmcgYSBsYXJnZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm51bWJlciBv ZiBwaG9uZSBudW1iZXJzLCBhbmQgd2hlbiBrZWVwLWFsaXZlIG1lc3NhZ2VzIGFyZSB1c2VkLjwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPldoaWxlIHNvbWUgaW1wbGVtZW50YXRpb25z IHVzZXMgdHJpY2tzIHN1Y2ggYXMgcmVnaXN0ZXJpbmcgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mcXVvdDtkaWFsbGluZyBwcmVmaXhlcyZxdW90OyB0byBtYXAgdG8gdGVsZXBob25lIG51bWJl ciwgaXQgaXMgbm90IHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aW50ZW50IG9mIHByZWZp eGVzIHdoaWNoIGFyZSBzdXBwb3NlZCB0byBiZSB1c2VkIGZvciBzcGVjaWFsIHNlcnZpY2VzLjwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPk5vcm1hbGx5LCBhIGdhdGV3YXkgcmVnaXN0 ZXJzIGFuIGFsaWFzIHdpdGggaXRzIGdhdGVrZWVwZXIgYW5kIHRoZSBiaW5kaW5nIGJldHdlZW4g dGhlIGFsaWFzIGFuZCB0aGUgcmFuZ2Ugb2YgcGhvbmUgbnVtYmVycyBoYW5kbGVkIGJ5IHRoZSA8 L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Z2F0ZXdheSBpcyAmcXVvdDttYW51YWxseSZx dW90OyBjb25maWd1cmVkIGluIHRoZSBnYXRla2VlcGVyLCBhcyBkZXNjcmliZWQ8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPmluIHRoZSBkcmFmdC4gSSB3b3VsZCB0aGluayB0aGF0IFRSSVAgY291 bGQgYXV0b21hdGUgdGhpcyBwcm9jZXNzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgRnJvbTogSm9uYXRoYW4gUm9zZW5iZXJnIFs8QSBIUkVGPSJtYWlsdG86amRyb3NlbkBk eW5hbWljc29mdC5jb20iPm1haWx0bzpqZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbTwvQT5dPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAwOSwgMjAwMCAx MTozMyBQTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUbzogc2lwQGxpc3RzLnJlc2Vh cmNoLmJlbGwtbGFicy5jb207IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpcHRlbEBs aXN0cy5yZXNlYXJjaC5iZWxsLWxhYnMuY29tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IFN1YmplY3Q6IFRSSVAgZm9yIGdhdGV3YXkgcmVnaXN0cmF0aW9uczwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IEZvbGtzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgRXZlcnkgb25jZSBpbiBhIHdoaWxlLCB0aGUg cXVlc3Rpb24gY29tZXMgdXAgb2Ygd2h5IFNJUCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgUkVHSVNURVIgaXMgbm90PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoZSByaWdo dCB2ZWhpY2xlIGZvciBhbGxvd2luZyBnYXRld2F5cyB0byByZWdpc3RlciBwaG9uZSA8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcHJlZml4ZXMgd2l0aDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyBhIHByb3h5LiBJIGJlbGlldmUgVFJJUCBpcyBmYXIgYmV0dGVyIGZvciB0aGlz IHB1cnBvc2UuIEFzIGl0IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0dXJucyBvdXQs PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGEgc21hbGwgc3Vic2V0IG9mIFRSSVAgaXMg bmVlZGVkIHRvIHNvbHZlIHRoaXMgcHJvYmxlbSwgYW5kIHlldCBpdHM8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgc3RpbGwgaW50ZXJvcGVyYWJsZSB3aXRoIGZ1bGwgYmxvd24gVFJJUC4g SHVzc2VpbiBTYWxhbWEgYW5kIEkgaGF2ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB3 cml0dGVuIGFuIEktRCB0aGF0IGRpc2N1c3NlcyB0aGlzLiBVbnRpbCBpdCBhcHBlYXJzIGluIHRo ZSBhcmNoaXZlcyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgeW91IGNhbiBwaWNrIHVw IGEgY29weSBhdDo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7IDxBIEhSRUY9Imh0dHA6Ly93d3cuY3MuY29sdW1iaWEuZWR1L35qZHJv c2VuL3BhcGVycy9kcmFmdC1ycy10cmlwLWd3LTAwLnR4dCIgVEFSR0VUPSJfYmxhbmsiPmh0dHA6 Ly93d3cuY3MuY29sdW1iaWEuZWR1L35qZHJvc2VuL3BhcGVycy9kcmFmdC1ycy10cmlwLWd3LTAw LnR4dDwvQT48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IFRoYW5rcyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSm9uYXRo YW4gUi48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgLS0gPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IEpvbmF0aGFuIEQuIFJvc2VuYmVyZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDAg RXhlY3V0aXZlIERyaXZlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IENoaWVmIFNjaWVu dGlzdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBTdWl0ZSAxMjAgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGR5bmFtaWNzb2Z0Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdlc3QgT3JhbmdlLCBOSiAwNzA1MjwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBqZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGQVg6Jm5ic3A7Jm5i c3A7ICg3MzIpIDc0MS00Nzc4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDxBIEhSRUY9 Imh0dHA6Ly93d3cuY3MuY29sdW1iaWEuZWR1L35qZHJvc2VuIiBUQVJHRVQ9Il9ibGFuayI+aHR0 cDovL3d3dy5jcy5jb2x1bWJpYS5lZHUvfmpkcm9zZW48L0E+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBIT05FOiAoNzMyKSA3NDEtNzI0NDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8QSBIUkVGPSJodHRwOi8vd3d3LmR5bmFtaWNzb2Z0LmNv bSIgVEFSR0VUPSJfYmxhbmsiPmh0dHA6Ly93d3cuZHluYW1pY3NvZnQuY29tPC9BPjwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9G T05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ --0__=MxOdF2ZYnZL1QmzJNFii2izWWQGKJiP6THgwh8QrcuTNr9Vg8dbQSa4Q-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 20:06:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23507 for ; Mon, 8 May 2000 20:06:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF97044591; Mon, 8 May 2000 17:41:35 -0400 (EDT) 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 388F344569 for ; Mon, 8 May 2000 17:31:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:37:05 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 707D3443C1; Mon, 8 May 2000 14:21:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 47E86443AF for ; Mon, 8 May 2000 14:21:48 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 291ED52B6; Mon, 8 May 2000 14:21:47 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 014E152BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18410 for ; Mon, 8 May 2000 06:06:16 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 06:00:08 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 06:00:05 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA125820; Mon, 8 May 2000 19:54:39 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA69198; Mon, 8 May 2000 19:59:56 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E8C5 ; Mon, 8 May 2000 19:59:45 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: archow@hss.hns.com Cc: "Adam B. Roach" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:12 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Two New Drafts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I think we are once again jumping the gun a bit. There are some much bigger issues to address with a generic sip subscription/notification mechanism: 1. what entities are generating the notifications? It can be a UA, or it could be a proxy or registrar. 2. What are the types of events we want to support subscriptions for? I know Adam has tried to keep that the subject of future extensions. Problem is, this issue has a strong impact on the addressing, event description and scaling capabilities. I don't think we can leave this to future extensions without having the "base" version have nothing but two methods. That doesn't really help much. I think we can define reasonably broad classes of events. Certainly we aren't interested in supporting events like "let me know when the coffee machine is done". 3. To whom does one address a subscription? If we address it to a user, what does that mean? Are we asking for a subscription to that users registration state? Also, before we get to far with architecture and design issues, there is the question about whether this concept, in general, is something the working group is interested in pursuing. -Jonathan R. archow@hss.hns.com wrote: > > Hi, > responses embedded and preceded by ARC> > > >The draft does not mention what happens when multiple SUBSCRIBE requests > >arrive from the same user. In REGISTER, > > they replace old ones if the SIP url is same and additive otherwise. > >However, in SUBSCRIBE, I think it would make sense to make it additive > >only, since the same SIP url can subscribe to multiple events using diff. > >subscription messages. Is this correct ? > > That sounds good, except possibly for the same "call leg". I think the > part that needs to be clarified is: if a user sends a SUBSCRIBE > which has the same Call-ID, From, and To as a previous request, > does it add events or override them? I'm leaning towards overrriding > events, since there is no easy way to remove events otherwise. Note well > that this wouldn't apply to other subscriptions with different Call-IDs, > which would (of course) remain additive. > > ARC> Somehow, I feel Call-ID and suscription should not be tied together. > This is primarily > ARC> because callid is generated by a terminal and a user has no control > over it. > ARC> However, a subscription is for a user, not a terminal. so if I > subscribe to a set of services > ARC> today, if I travel tomorrow, I want to walk into a Cyber Cafe, log in > using some applet based > ARC> sip client that will generate a different Call-ID from my old desktop > one an still be able to > ARC> access my old subscription list and add/del from it without having to > know the Call-Id - which > ARC> in many cases, I never get to see as a user. > ARC> but the moment the backend notifier works on Call-ID - then I would > never be able to 'Add' to > ARC> my list since Ill be using a different Call-ID in all probability, > neither will I be able to > ARC> somehow retrieve the old one, since match will never be true. > ARC> This is why I feel subscription should not be linked to a call - id. > > (Incidentally, I like your example. I have recently had > discussions with several different groups of people who > wanted to know how one would go about, for example, having > a light blink on your phone and/or have a distinctive dial > tone when a message is waiting). > > ARC> Well, we actually had exactly the above requirement once, and we did > it my adding > ARC> an Event like field with more or less the same semantics as we > discussed above. > > >Event = 1#(eventid ; duration) > >event = token // Does it need to be broken ? > >duration = deltaseconds | SIP-Date > > I don't really like this. Beyond the problems with using > commas for separators *and* having commas appear in > the duration (if the SIP-Date format is used), I'm trying to > keep it as congruent as possible with REGISTER, since the > semantics for that are already well defined -- and code is > already written to handle it. For the above situation, I'd > propose that you either: a) send all three REGISTER messages, > with different Call-IDs, in a single UDP packet, or b) send > a single REGISTER for all three events with an expires of 2 > hours. At the end of the 2 hours, re-SUBSCRIBE for just B > and C (expires in one hour), and one hour later, re-SUBSCRIBE > for just C. (A variation on this theme would be to subscribe > for 4 hours, override it in 2, and then again one hour later; > I prefer this method, since it eliminates the chances of missing > events -- although it counts on the addition vs. replacement > semantics I describe above). > > ARC> I assume where ever you mentioned REGISTER above , you meant SUBSCRIBE > ARC> Again, solution 1 is to me, a kind of loose workaround. And the other > solutions > ARC> force the client to maintain time differentiators actively since it > must physically > ARC> maniuplate subscriptions to implement the common requirement above. > Rather, The > ARC> Notifier is actually already implementing a timer list which can > notify users > ARC> based on differential time values maybe, so why force the client into > maintain the > ARC> differential list also ? To me it seems to be much cleaner for the > client to specify > ARC> it once, and forget about it, as the notifier server is there just to > remind him anyway > ARC> so why bog him down with keeping track of such requests ? > ARC> The only -ve point seems to be parsing for commas (which is a non > issue for good parsers) > ARC> - but if that really is a problem, maybe we could work at a simpler > expiry type ? > ARC> However, I dont feel parsing should be the reason to adopt the > alternate methods suggested > ARC> above. What do you/others feel abt it ? > > I must have been somewhat unclear. I am not proposing that one > use REGISTER itself to cancel a subscription; merely that one > use the same *mechanism*, with a SUBSCRIBE method. For > example, let's say that I want to cancel the subscription(s) > above. I could do so by sending: > > ARC> Sorry, I misinterpreted, then. Seems fine to me. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 20:07:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23544 for ; Mon, 8 May 2000 20:07:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4CF8B4459D; Mon, 8 May 2000 17:46:06 -0400 (EDT) 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 28C1844596 for ; Mon, 8 May 2000 17:45:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:50:12 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3459B443C6; Mon, 8 May 2000 14:21:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0657D443AF for ; Mon, 8 May 2000 14:21:52 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5478D52AB; Mon, 8 May 2000 14:21:51 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id ABBFF52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18285 for ; Mon, 8 May 2000 06:00:17 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:02 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:57:59 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA164244 for ; Mon, 8 May 2000 19:52:33 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA42140 for ; Mon, 8 May 2000 19:57:50 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036B991 ; Mon, 8 May 2000 19:57:44 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:03 +0530 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=26zFeI2BrVTOhCPb7Tg1VqYu4yBtzHJBzIRsbOS3kPQpktDuQNVoRvTQ" Content-Disposition: inline Subject: [SIP] New I-D available soon - Java enhanced SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --0__=26zFeI2BrVTOhCPb7Tg1VqYu4yBtzHJBzIRsbOS3kPQpktDuQNVoRvTQ Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I've posted an Internet Draft to the internet draft archives which describes an extension to SIP to build on some of the strengths of Java, the JVM concept and Java Mobile agents. It is not intended to discuss this at Adelaide as it is an initial draft but I would be interested in getting feedback and comments from anybody who takes a look at it. The ID defines the extension to the SIP protocol and describes how it is intended to: - extend SIP messages to carry Java applets or Java applets plus their state and runtime contexts - in other words Java mobile agents (or URLs to either the applet or the Java Mobile agent) - to define a Java SIP API which will allow the Java applet or Java Mobile Agent interact with the receiving host system and receiving SIP client - to extend the SIP client so that the Java applet or Java Mobile Agent is run before any other actions are taken on the receipt of a message by the receiving host SIP client. It also includes security measures to allow a client to be configured to enable and disable certain actions between the JVM running the Java applet or the Java mobile agent virtual machine running the Java Mobile Agent in the message and the clients SIP client and host system. Cheers, Mick O'Doherty Nortel Networks ---------------------------------------------------------------------------- --------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Java enhanced SIP (JES) Author(s) : M. O'Doherty Filename : draft-odoherty-sip-java-enhanced-00.txt Pages : 9 Date : 08-Mar-00 This document defines an extension to the SIP [2] protocol to do a number of things - to extend SIP messages to carry Java applets or Java Mobile Agents, to define a Java SIP API which will allow the Java applet or Java Mobile Agent to interact with the receiving host system and to extend the SIP protocol client so that the Java applet or Java Mobile Agent is run before any other actions are taken on the receipt of a message by the receiving host SIP client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-odoherty-sip-java-enhanced-00.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-odoherty-sip-java-enhanced-00.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 ---------------------------------------------------------------------------- ----------------------------------- --0__=26zFeI2BrVTOhCPb7Tg1VqYu4yBtzHJBzIRsbOS3kPQpktDuQNVoRvTQ Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1MS42NSI+DQo8VElUTEU+TmV3IEkt RCBhdmFpbGFibGUgc29vbiAtIEphdmEgZW5oYW5jZWQgU0lQPC9USVRMRT4NCjwvSEVBRD4NCjxC T0RZPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQ29taWMgU2FucyBNUyI+SGksPC9GT05UPg0K PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQ29taWMgU2FucyBNUyI+SSd2ZSBwb3N0ZWQg YW4gSW50ZXJuZXQgRHJhZnQgdG8gdGhlIGludGVybmV0IGRyYWZ0IGFyY2hpdmVzIHdoaWNoIGRl c2NyaWJlcyBhbiBleHRlbnNpb24gdG8gU0lQIHRvIGJ1aWxkIG9uIHNvbWUgb2YgdGhlIHN0cmVu Z3RocyBvZiBKYXZhLCB0aGUgSlZNIGNvbmNlcHQgYW5kIEphdmEgTW9iaWxlIGFnZW50cy48L0ZP TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJDb21pYyBTYW5zIE1TIj5JdCBpcyBub3QgaW50 ZW5kZWQgdG8gZGlzY3VzcyB0aGlzIGF0IEFkZWxhaWRlIGFzIGl0IGlzIGFuIGluaXRpYWwgZHJh ZnQgYnV0IEkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBnZXR0aW5nIGZlZWRiYWNrIGFuZCBjb21t ZW50cyBmcm9tIGFueWJvZHkgd2hvIHRha2VzIGEgbG9vayBhdCBpdC48L0ZPTlQ+PC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTIgRkFDRT0iQ29taWMgU2FucyBNUyI+VGhlIElEIGRlZmluZXMgdGhlIGV4 dGVuc2lvbiB0byB0aGUgU0lQIHByb3RvY29sIGFuZCBkZXNjcmliZXMgaG93IGl0IGlzIGludGVu ZGVkIHRvOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkNvbWljIFNhbnMg TVMiPi0gZXh0ZW5kIFNJUCBtZXNzYWdlcyB0byBjYXJyeSBKYXZhIGFwcGxldHMgb3IgSmF2YSBh cHBsZXRzIHBsdXMgdGhlaXIgc3RhdGUgYW5kIHJ1bnRpbWUgY29udGV4dHMgLSBpbiBvdGhlciB3 b3JkcyZuYnNwOyBKYXZhIG1vYmlsZSBhZ2VudHMgKG9yIFVSTHMgdG8gZWl0aGVyIHRoZSBhcHBs ZXQgb3IgdGhlIEphdmEgTW9iaWxlIGFnZW50KTwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9 MiBGQUNFPSJDb21pYyBTYW5zIE1TIj4tIHRvIGRlZmluZSBhIEphdmEgU0lQIEFQSSB3aGljaCB3 aWxsIGFsbG93IHRoZSBKYXZhIGFwcGxldCBvciBKYXZhIE1vYmlsZSBBZ2VudCBpbnRlcmFjdCB3 aXRoIHRoZSByZWNlaXZpbmcgaG9zdCBzeXN0ZW0gYW5kIHJlY2VpdmluZyBTSVAgY2xpZW50PC9G T05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkNvbWljIFNhbnMgTVMiPi0gdG8gZXh0 ZW5kIHRoZSBTSVAgY2xpZW50IHNvIHRoYXQgdGhlIEphdmEgYXBwbGV0IG9yIEphdmEgTW9iaWxl IEFnZW50IGlzIHJ1biBiZWZvcmUgYW55IG90aGVyIGFjdGlvbnMgYXJlIHRha2VuIG9uIHRoZSBy ZWNlaXB0IG9mIGEgbWVzc2FnZSBieSB0aGUgcmVjZWl2aW5nIGhvc3QgU0lQIGNsaWVudC48L0ZP TlQ+PC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZB Q0U9IkNvbWljIFNhbnMgTVMiPkl0IGFsc28gaW5jbHVkZXMgc2VjdXJpdHkgbWVhc3VyZXMgdG8g YWxsb3cgYSBjbGllbnQgdG8gYmUgY29uZmlndXJlZCB0byBlbmFibGUgYW5kIGRpc2FibGUgY2Vy dGFpbiBhY3Rpb25zIGJldHdlZW4gdGhlIEpWTSBydW5uaW5nIHRoZSBKYXZhIGFwcGxldCBvciB0 aGUgSmF2YSBtb2JpbGUgYWdlbnQgdmlydHVhbCBtYWNoaW5lIHJ1bm5pbmcgdGhlPC9GT05UPiA8 Rk9OVCBTSVpFPTIgRkFDRT0iQ29taWMgU2FucyBNUyI+SmF2YSBNb2JpbGUgQWdlbnQ8L0ZPTlQ+ PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJDb21pYyBTYW5zIE1TIj4gaW4gdGhl IG1lc3NhZ2UgYW5kIHRoZSBjbGllbnRzIFNJUCBjbGllbnQgYW5kIGhvc3Qgc3lzdGVtLjwvRk9O VD48L1A+DQoNCjxQPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFDRT0iQ29taWMgU2Fu cyBNUyI+Q2hlZXJzLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJ WkU9MiBGQUNFPSJDb21pYyBTYW5zIE1TIj5NaWNrIE8nRG9oZXJ0eTwvRk9OVD4NCjxCUj48Rk9O VCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkNvbWljIFNhbnMgTVMiPk5vcnRlbCBOZXR3 b3JrczwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNF PSJDb21pYyBTYW5zIE1TIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjwvRk9OVD4N CjwvUD4NCjxCUj4NCg0KPFA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGl0bGUmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSmF2YSBlbmhhbmNlZCBTSVAgKEpF Uyk8L0ZPTlQ+DQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QXV0aG9yKHMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDogTS4gTydEb2hlcnR5PC9GT05UPg0KPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZp bGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQt b2RvaGVydHktc2lwLWphdmEtZW5oYW5jZWQtMDAudHh0PC9GT05UPg0KPEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi PlBhZ2VzJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA6IDk8L0ZPTlQ+DQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAwOC1NYXItMDA8L0ZP TlQ+DQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJS PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGV4dGVu c2lvbiB0byB0aGUgU0lQIFsyXSBwcm90b2NvbCB0byBkbyBhIDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTIgRkFDRT0iQXJpYWwiPm51bWJlciBvZiB0aGluZ3MgLSB0byBleHRlbmQgU0lQIG1lc3Nh Z2VzIHRvIGNhcnJ5IEphdmEgYXBwbGV0cyBvciA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB Q0U9IkFyaWFsIj5KYXZhIE1vYmlsZSBBZ2VudHMsIHRvIGRlZmluZSBhIEphdmEgU0lQIEFQSSB3 aGljaCB3aWxsIGFsbG93IHRoZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs Ij5KYXZhIGFwcGxldCBvciBKYXZhIE1vYmlsZSBBZ2VudCB0byBpbnRlcmFjdCB3aXRoIHRoZSBy ZWNlaXZpbmcgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aG9zdCBzeXN0 ZW0gYW5kIHRvIGV4dGVuZCB0aGUgU0lQIHByb3RvY29sIGNsaWVudCBzbyB0aGF0IHRoZSBKYXZh IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmFwcGxldCBvciBKYXZhIE1v YmlsZSBBZ2VudCBpcyBydW4gYmVmb3JlIGFueSBvdGhlciBhY3Rpb25zIGFyZSA8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj50YWtlbiBvbiB0aGUgcmVjZWlwdCBvZiBhIG1l c3NhZ2UgYnkgdGhlIHJlY2VpdmluZyBob3N0IFNJUCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y IEZBQ0U9IkFyaWFsIj5jbGllbnQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFD RT0iQXJpYWwiPkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjwvRk9OVD4NCjxCUj48 VT48Rk9OVCBDT0xPUj0iIzAwMDBGRiIgU0laRT0yIEZBQ0U9IkFyaWFsIj48QSBIUkVGPSJodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1vZG9oZXJ0eS1zaXAtamF2YS1l bmhhbmNlZC0wMC50eHQiIFRBUkdFVD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1vZG9oZXJ0eS1zaXAtamF2YS1lbmhhbmNlZC0wMC50eHQ8L0E+PC9G T05UPjwvVT4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2luIHdpdGggdGhl IHVzZXJuYW1lPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+JnF1b3Q7YW5v bnltb3VzJnF1b3Q7IGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFmdGVy IGxvZ2dpbmcgaW4sPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dHlwZSAm cXVvdDtjZCBpbnRlcm5ldC1kcmFmdHMmcXVvdDsgYW5kIHRoZW48L0ZPTlQ+DQo8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9MiBGQUNFPSJB cmlhbCI+JnF1b3Q7Z2V0IGRyYWZ0LW9kb2hlcnR5LXNpcC1qYXZhLWVuaGFuY2VkLTAwLnR4dCZx dW90Oy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QSBsaXN0 IG9mIEludGVybmV0LURyYWZ0cyBkaXJlY3RvcmllcyBjYW4gYmUgZm91bmQgaW48L0ZPTlQ+DQo8 QlI+PFU+PEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBGQUNFPSJBcmlhbCI+PEEgSFJFRj0i aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCIgVEFSR0VUPSJfYmxhbmsiPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8L0E+PC9GT05UPjwvVT48Rk9OVCBTSVpFPTIgRkFDRT0i QXJpYWwiPiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vcjwvRk9OVD48 VT4gPEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBGQUNFPSJBcmlhbCI+PEEgSFJFRj0iZnRw Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiIFRBUkdFVD0iX2JsYW5rIj5m dHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvQT48L0ZPTlQ+PC9VPg0K PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hU TUw+ --0__=26zFeI2BrVTOhCPb7Tg1VqYu4yBtzHJBzIRsbOS3kPQpktDuQNVoRvTQ-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 20:34:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23997 for ; Mon, 8 May 2000 20:34:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7DBD444A8; Mon, 8 May 2000 16:27:12 -0400 (EDT) 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 EBD914446C for ; Mon, 8 May 2000 16:25:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:31:16 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 79E5C44393; Mon, 8 May 2000 14:21:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0B2D244391 for ; Mon, 8 May 2000 14:21:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1F46152BB; Mon, 8 May 2000 14:21:11 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 6C50E52C4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id HAA19891 for ; Mon, 8 May 2000 07:58:16 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:56:01 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:55:59 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA64940; Mon, 8 May 2000 21:50:52 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA46270; Mon, 8 May 2000 21:55:51 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.004186E3 ; Mon, 8 May 2000 21:55:43 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Igor Slepchin Cc: Sunitha Kumar , SIPbell-labs Message-ID: Date: Mon, 8 May 2000 14:10:17 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: BYE and record route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Let me make a general comment here on mailing list usage. The SIP mailing list is an excellent place to address questions regarding the specification. However, the purpose of the list is to work on our deliverables as a working group. Time spent by the group answering questions that have been discussed before is less time the group can spend making forward progress on our documents. So, to try and keep focused, I would encourage people to do the following. Before asking your question to the list, please check the FAQ, the archives, and the rfc2543bis draft to see if your question is answered there. If not, then of course go ahead and ask on the list. Thanks, Jonathan R. Igor Slepchin wrote: > > It certainly should, and not only for BYE requests. This is discussed in > http://www.cs.columbia.edu/~hgs/sip/notes.html (see the note on > Record-Route towards the end of the document) and in > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf > (section 6.3.33). > > --- > Igor Slepchin > > > Sunitha Kumar wrote: > > > > It is given that the record route in 200 OK is copied into the Route > > headers for subsequent requests from the caller. My question was, if > > we needed to make the BYE from the *callee* traverse the same set of > > proxies, then should this be rememberd from the INVITE request > > obtained from the caller, or does the via field help in that. > > > > Thanks! > > > > -- > > Sunitha Kumar > > Software Engineer > > Vovida Networks > > (408) 957 - 6374 > > > > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 20:36:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24016 for ; Mon, 8 May 2000 20:36:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C66B7444E0; Mon, 8 May 2000 16:52:14 -0400 (EDT) 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 5C55D444DD for ; Mon, 8 May 2000 16:51:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:57:37 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5A6EA443A4; Mon, 8 May 2000 14:21:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0E70B443A8 for ; Mon, 8 May 2000 14:21:29 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1092252D0; Mon, 8 May 2000 14:21:28 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 677DB52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18400 for ; Mon, 8 May 2000 06:06:02 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 06:00:05 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 06:00:04 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA88904; Mon, 8 May 2000 19:54:55 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA69194; Mon, 8 May 2000 19:59:55 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E95A ; Mon, 8 May 2000 19:59:46 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "James M. Polk" Cc: sip@lists.research.bell-labs.com, "iptel, list" Message-ID: Date: Mon, 8 May 2000 14:10:12 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Gateways and registration Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com "James M. Polk" wrote: > > All > > Parallel question on the reliance of TRIP -- isn't it based on using > BGP? If that is strickly true, what happens to the SIP Device if BGP > isn't deployed within a VoIP network domain that still wants to locate > the Gateway? TRIP borrows many ideas from BGP, but it in no way whatsoever requires BGP to actually be running on routers in the network. TRIP runs at the application layer, between location servers. It doesn't matter one drop what the underlying layer 3 routing protocols are. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 20:39:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24068 for ; Mon, 8 May 2000 20:39:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CCF244470; Mon, 8 May 2000 16:27:19 -0400 (EDT) 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 EFD8E4446F for ; Mon, 8 May 2000 16:25:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 16:31:16 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9BC8D44394; Mon, 8 May 2000 14:21:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 722EF44383 for ; Mon, 8 May 2000 14:21:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CD29A52BB; Mon, 8 May 2000 14:21:12 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id E22B152B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id HAA19920 for ; Mon, 8 May 2000 07:59:32 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:55:18 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:55:17 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA83622; Mon, 8 May 2000 21:49:52 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA71464; Mon, 8 May 2000 21:55:08 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00417738 ; Mon, 8 May 2000 21:55:03 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Anders Kristensen Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:18 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Provisional Response Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Anders Kristensen wrote: > > The draft talks about when it's OK to generate new reliable responses > for a transaction, but it doesn't seem to say anything about whether > final responses can be generated by a UAS which has outstanding > unacknowledged reliable responses. > > I believe the UAS must be allowed to generate a final response at any > time. Yes, agreed. > > The question is what happens with existing 'orphan' reliable responses > and corresponding PRACKS. They can either terminate normally, i.e. the > UAS continue retransmitting those reliable responses as it would have > done had a final response not been sent and likewise the UAC still > PRACKS them, or else maybe they could be terminated somehow - the UAS > stops retransmitting them, and the UAC never PRACKS anything for which > it has received a final response. Hmm. Good question. I tend to lean towards having those orphaned provisional responses still be PRACKED. Here's my reasoning: 1. These responses were sent reliably since they contain some important and useful information. It may be that this information is no longer useful once the final response is sent, but then again, it may be that it is still useful. So, if the user tries to send a provisional response reliably, lets always deliver it. Let the application decide whether its useful after a final response. 2. Lets keep transactions independent. We went through a similar thing with CANCEL, and the state machines were confusing until we decided to make CANCEL a mini-transaction that does nothing but ask the UAS to quickly answer the request. I think we will see confusion in the PRACK processing if its operation becomes dependent on events in other transactions. -Jonathan R. > > Anders > > -- > Anders Kristensen , > http://www-uk.hpl.hp.com/people/ak/ > Hewlett-Packard Labs, Bristol, UK -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 20:45:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24131 for ; Mon, 8 May 2000 20:45:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4AD2B4443E; Mon, 8 May 2000 16:03:36 -0400 (EDT) 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 D9ED944442 for ; Mon, 8 May 2000 15:59:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:04:56 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8DF4A44374; Mon, 8 May 2000 14:20:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0A14644365 for ; Mon, 8 May 2000 14:20:22 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DB6BD52C8; Mon, 8 May 2000 14:20:22 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 12DBC52AB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20301 for ; Mon, 8 May 2000 08:07:18 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 08:00:10 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 08:00:09 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA168998 for ; Mon, 8 May 2000 21:54:44 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA31456 for ; Mon, 8 May 2000 22:00:00 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041EA49 ; Mon, 8 May 2000 21:59:58 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: SIPbell-labs Message-ID: Date: Mon, 8 May 2000 14:10:31 +0530 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=YnUkTU9MrarZUio3yCC7YDjQxWRNCxhldRwsYMcDhwejfQy42xYRf482" Content-Disposition: inline Subject: [SIP] question on sip url grammar. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --0__=YnUkTU9MrarZUio3yCC7YDjQxWRNCxhldRwsYMcDhwejfQy42xYRf482 Content-type: text/plain; charset=us-ascii Content-Disposition: inline A question on BNF grammar in SIP url. In BNF RFC, it is given that [ stands for 0 or 1 times the value. It is given SIP-URL = "sip:" [userinfo '@'] hostport url-parameters.... user-info = user [":"password] user = *(unreserved... ) //optional password = *(unreserved ...) //optional. so, this leads to a url as: sip::@hostport. So, with the above grammar, this is valid. is my understanding right? Also, for hostport; sip:userinfo@host:urlparms //since port is optional. Thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --0__=YnUkTU9MrarZUio3yCC7YDjQxWRNCxhldRwsYMcDhwejfQy42xYRf482 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KQSBxdWVzdGlvbiBvbiBCTkYgZ3JhbW1hciBpbiBTSVAgdXJsLg0KPGJy PkluIEJORiBSRkMsIGl0IGlzIGdpdmVuIHRoYXQgWyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0Kc3RhbmRzIGZvciAwIG9yIDEgdGltZXMgdGhlIHZhbHVlLg0KPGJyPkl0IGlz IGdpdmVuDQo8cD5TSVAtVVJMID0gInNpcDoiJm5ic3A7IFt1c2VyaW5mbyAnQCddIGhvc3Rwb3J0 IHVybC1wYXJhbWV0ZXJzLi4uLg0KPGJyPnVzZXItaW5mbyA9IHVzZXIgWyI6InBhc3N3b3JkXQ0K PGJyPnVzZXIgPSAqKHVucmVzZXJ2ZWQuLi4gKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KLy9vcHRpb25hbA0KPHA+cGFzc3dvcmQgPSAqKHVucmVzZXJ2ZWQgLi4uKSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KLy9vcHRpb25hbC4NCjxwPnNvLCB0 aGlzIGxlYWRzIHRvIGEgdXJsIGFzOg0KPHA+c2lwOjpAaG9zdHBvcnQuJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpTbywgd2l0aCB0aGUgYWJvdmUgZ3JhbW1h ciwgdGhpcyBpcyB2YWxpZC4NCjxicj5pcyBteSB1bmRlcnN0YW5kaW5nIHJpZ2h0Pw0KPHA+QWxz bywgZm9yIGhvc3Rwb3J0Ow0KPHA+c2lwOnVzZXJpbmZvQGhvc3Q6dXJscGFybXMmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Ci8vc2luY2UgcG9ydCBpcyBvcHRpb25hbC4NCjxwcmU+PC9wcmU+DQoNCjxwcmU+VGhhbmtzIG11 Y2ghPC9wcmU+DQoNCjxwcmU+LS0mbmJzcDsNClN1bml0aGEgS3VtYXINClNvZnR3YXJlIEVuZ2lu ZWVyDQpWb3ZpZGEgTmV0d29ya3MNCig0MDgpIDk1NyAtIDYzNzQ8L3ByZT4NCiZuYnNwOzwvaHRt bD4NCg0K --0__=YnUkTU9MrarZUio3yCC7YDjQxWRNCxhldRwsYMcDhwejfQy42xYRf482-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 20:50:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24153 for ; Mon, 8 May 2000 20:49:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BED1844466; Mon, 8 May 2000 16:14:43 -0400 (EDT) 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 794474446C for ; Mon, 8 May 2000 16:13:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:18:07 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 023B944388; Mon, 8 May 2000 14:21:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BC9F844383 for ; Mon, 8 May 2000 14:21:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B3B7852AB; Mon, 8 May 2000 14:21:02 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id C338B52B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20028 for ; Mon, 8 May 2000 08:00:45 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 07:56:15 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:56:13 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA188278; Mon, 8 May 2000 21:49:42 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA68574; Mon, 8 May 2000 21:54:59 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.004173D7 ; Mon, 8 May 2000 21:54:54 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: IETF SIP Cc: Jonathan Rosenberg , Joerg Ott Message-ID: Date: Mon, 8 May 2000 14:10:17 +0530 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=8mVGgN0Wuqy6GVJbXPsrJAthSZt3O2drdNjGyHLkq8AdjCjq9ZfTIMju" Content-Disposition: inline Subject: [SIP] Revised Agenda for SIP WG at IETF 47 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --0__=8mVGgN0Wuqy6GVJbXPsrJAthSZt3O2drdNjGyHLkq8AdjCjq9ZfTIMju Content-type: text/plain; charset=us-ascii Content-Disposition: inline Ok, I asked for glaring errors in our first agenda draft, and YOU PEOPLE FOUND SOME! Darn. So, I've revised the agenda and posted it anew at: http://www.softarmor.com/sipwg/meets/IETF47/agenda.html and attached an HTML version to this email. Note that we are getting a rather seriously packed agenda. I propose that we settle further scheduling conflicts with noble denial-of-service duels at dawn. Two kernels, one hub, pings of death . . . -- Dean Willis SIP WG co-chair --0__=8mVGgN0Wuqy6GVJbXPsrJAthSZt3O2drdNjGyHLkq8AdjCjq9ZfTIMju Content-type: text/html; name="Agenda, IETF 47, SIP WG.htm" Content-Disposition: attachment; filename="Agenda, IETF 47, SIP WG.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjwhLS0gc2F2ZWQgZnJvbSB1cmw9KDAwNTUpaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29t L3NpcHdnL21lZXRzL0lFVEY0Ny9hZ2VuZGEuaHRtbCAtLT4NCjxIVE1MPjxIRUFEPjxUSVRMRT5B Z2VuZGEsIElFVEYgNDcsIFNJUCBXRzwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9d2luZG93cy0xMjUyIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNv bnRlbnQ9Ik1TSFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJP RFk+DQo8SDE+QWdlbmRhLCBJRVRGIDQ3IFNJUCBXRyBTZXNzaW9uIChEcmFmdCk8L0gxPg0KPFA+ UHJvcG9zZWQgZHJhZnQgcGVuZGluZyBjaGFpciByZXZpZXcuPC9QPg0KPEhSPg0KDQo8UD48U1RS T05HPk1vbmRheSwgTWFyY2ggMjcsIDIwMDA8QlI+MDkzMCAtIDExMzA8L1NUUk9ORz48L1A+DQo8 VEFCTEUgYm9yZGVyPTEgaGVpZ2h0PTQ4NiB3aWR0aD0iMTAwJSI+DQogIDxUQk9EWT4NCiAgPFRS Pg0KICAgIDxURCBoZWlnaHQ9MTkgd2lkdGg9IjIwJSI+PFNUUk9ORz48VT5QcmVzZW50ZXI8L1U+ PC9TVFJPTkc+PC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSI0NSUiPjxTVFJPTkc+PFU+ VGl0bGU8L1U+PC9TVFJPTkc+PC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSIxMCUiPjxT VFJPTkc+PFU+VGltZTwvVT48L1NUUk9ORz48L1REPg0KICAgIDxURCBoZWlnaHQ9MTkgd2lkdGg9 IjI1JSI+PFNUUk9ORz48VT5Db250YWN0PC9VPjwvU1RST05HPjwvVEQ+PC9UUj4NCiAgPFRSPg0K ICAgIDxURCBoZWlnaHQ9MTkgd2lkdGg9IjIwJSI+Q2hhaXJzPC9URD4NCiAgICA8VEQgaGVpZ2h0 PTE5IHdpZHRoPSI0NSUiPkFnZW5kYSBCYXNoaW5nPC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdp ZHRoPSIxMCUiPjA5MzA8QlI+MDo1PC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSIyNSUi PmRlYW4ud2lsbGlzQHdjb20uY29tPC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0x OSB3aWR0aD0iMjAlIj5DaGFpcnM8L1REPg0KICAgIDxURCBoZWlnaHQ9MTkgd2lkdGg9IjQ1JSI+ TWlsZXN0b25lIFN0YXR1cw0KICAgICAgPFRBQkxFPg0KICAgICAgICA8VEJPRFk+DQogICAgICAg IDxUUj4NCiAgICAgICAgICA8VEQgdkFsaWduPXRvcCB3aWR0aD03MD5Hb2FsLzxCUj5TdGF0dXM8 L1REPg0KICAgICAgICAgIDxURD48L1REPg0KICAgICAgICAgIDxURD5UYXNrPC9URD48L1RSPg0K ICAgICAgICA8VFIgYWxpZ249bGVmdCB2QWxpZ249dG9wPg0KICAgICAgICAgIDxURCB2QWxpZ249 dG9wIHdpZHRoPTcwPkRlYyA5OTxCUj5GZWIgMDA8L1REPg0KICAgICAgICAgIDxURD4mbmJzcDsm bmJzcDs8L1REPg0KICAgICAgICAgIDxURD5JTkZPIE1ldGhvZCBleHRlbnNpb24gc3VibWl0dGVk IHRvIElFU0cgPC9URD48L1RSPg0KICAgICAgICA8VFIgYWxpZ249bGVmdCB2QWxpZ249dG9wPg0K ICAgICAgICAgIDxURCB2QWxpZ249dG9wIHdpZHRoPTcwPkZlYiAwMDxCUj5Tb29uPC9URD4NCiAg ICAgICAgICA8VEQ+Jm5ic3A7Jm5ic3A7PC9URD4NCiAgICAgICAgICA8VEQ+RWFybHkgc2Vzc2lv biBlc3RhYmxpc2htZW50IGV4dGVuc2lvbiBzdWJtaXR0ZWQgdG8gSUVTRzwvVEQ+PC9UUj4NCiAg ICAgICAgPFRSIGFsaWduPWxlZnQgdkFsaWduPXRvcD4NCiAgICAgICAgICA8VEQgdkFsaWduPXRv cCB3aWR0aD03MD5NYXIgMDA8QlI+U29vbjwvVEQ+DQogICAgICAgICAgPFREPiZuYnNwOyZuYnNw OzwvVEQ+DQogICAgICAgICAgPFREPkNhbGxlciBwcmVmZXJlbmNlcyBzcGVjaWZpY2F0aW9uIHN1 Ym1pdHRlZCB0byBJRVNHPC9URD48L1RSPg0KICAgICAgICA8VFIgYWxpZ249bGVmdCB2QWxpZ249 dG9wPg0KICAgICAgICAgIDxURCB2QWxpZ249dG9wIHdpZHRoPTcwPk1heSAwMDxCUj5PcGVuPC9U RD4NCiAgICAgICAgICA8VEQ+Jm5ic3A7Jm5ic3A7PC9URD4NCiAgICAgICAgICA8VEQ+Q2FsbCBj b250cm9sIHNwZWNpZmljYXRpb24gc3VibWl0dGVkIHRvIElFU0c8L1REPjwvVFI+DQogICAgICAg IDxUUiBhbGlnbj1sZWZ0IHZBbGlnbj10b3A+DQogICAgICAgICAgPFREIHZBbGlnbj10b3Agd2lk dGg9NzA+SnVsIDAwPEJSPk9wZW48L1REPg0KICAgICAgICAgIDxURD4mbmJzcDsmbmJzcDs8L1RE Pg0KICAgICAgICAgIDxURD5EcmFmdCBzdGFuZGFyZCB2ZXJzaW9uIG9mIFNJUCBzdWJtaXR0ZWQg dG8gSUVTRzwvVEQ+PC9UUj4NCiAgICAgICAgPFRSIGFsaWduPWxlZnQgdkFsaWduPXRvcD4NCiAg ICAgICAgICA8VEQgdkFsaWduPXRvcCB3aWR0aD03MD5KdWwgMDA8QlI+b3BlbjwvVEQ+DQogICAg ICAgICAgPFREPiZuYnNwOyZuYnNwOzwvVEQ+DQogICAgICAgICAgPFREPlNJUCBNSUIgc3VibWl0 dGVkIHRvIElFU0c8L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvVEQ+DQogICAgPFREIGhlaWdo dD0xOSB3aWR0aD0iMTAlIj4wOTM1PEJSPjA6NTwvVEQ+DQogICAgPFREIGhlaWdodD0xOSB3aWR0 aD0iMjUlIj5kZWFuLndpbGxpc0B3Y29tLmNvbTwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBo ZWlnaHQ9MTkgd2lkdGg9IjIwJSI+Q2hhaXJzPC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRo PSI0NSUiPkNoYXJ0ZXIgRGlzY3Vzc2lvbjxCUj5Db25zaWRlciBhcyBXRyBpdGVtcywgc2V0IA0K ICAgICAgbWlsZXN0b25lcyBmb3I6DQogICAgICA8VUw+DQogICAgICAgIDxMST5TSVAgU2VydmVy IEZlYXR1cmVzIE5lZ290aWF0aW9uIA0KICAgICAgICA8TEk+Q2FsbCBGbG93cyAoSW5mb3JtYXRp b25hbCkgDQogICAgICAgIDxMST5TSVAgU2Vzc2lvbiBUaW1lciANCiAgICAgICAgPExJPlJlbGlh YmlsaXR5IGZvciBQcm92aXNpb25hbCBNZXNzYWdlcyANCiAgICAgICAgPExJPlNJUC1UZWxlcGhv bnkgDQogICAgICAgIDxMST5Db252ZXJnZW5jZSB3aXRoIHRoZSBQYWNrZXRDYWJsZSBEQ1MgU3Bl YyAoPEEgDQogICAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy90ZWFt cy9zaXBkY3MvaW5kZXguaHRtbCI+RENTIA0KICAgICAgICBUZWFtPC9BPikgDQogICAgICAgIDxM ST5TZWN1cml0eSANCiAgICAgICAgPExJPlNpbmdsZSBMaW5lIEV4dGVuc2lvbiZuYnNwOyA8L0xJ PjwvVUw+PC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSIxMCUiPjA5NDA8QlI+MDo1PC9U RD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSIyNSUiPmRlYW4ud2lsbGlzQHdjb20uY29tPC9U RD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5Kb25hdGhhbiBS b3NlbmJlcmc8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1JSI+V0cgc3RhdHVzIGFu ZCBjdXJyZW50IGxpc3QgdG9waWNzPEJSPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0 YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1uYWlyLXNpcC1kaGNwLTAwLnR4dCI+ZHJhZnQt bmFpci1zaXAtZGhjcC0wMC50eHQ8L0E+PEJSPm90aGVyIA0KICAgICAgc3R1ZmYgZnJvbSBsaXN0 PC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIxMCUiPjA5NDU8QlI+MDoxNTwvVEQ+DQog ICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjUlIj48QSANCiAgICAgIGhyZWY9Im1haWx0bzpqZHJv c2VuQGR5bmFtaWNzb2Z0LmNvbSI+amRyb3NlbkBkeW5hbWljc29mdC5jb208L0E+PC9URD48L1RS Pg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5Kb25hdGhhbiBSb3NlbmJl cmcgPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUiPjxBIA0KICAgICAgaHJlZj0i aHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1pZXRmLXNpcC1jYWxs ZXJwcmVmcy0wMS50eHQiPmRyYWZ0LWlldGYtc2lwLWNhbGxlcnByZWZzLTAxLnR4dDwvQT48QlI+ V0cgDQogICAgICBjaGFydGVyIGl0ZW0sIHJldmlldyBjaGFuZ2VzLCBubyBvcGVuIGlzc3Vlcywg cGxhbiB0byBsYXN0IGNhbGwgZm9sbG93aW5nIA0KICAgICAgc2Vzc2lvbiB0aW1lciBhbmQgcmVs aWFibGUgcHJvdmlzaW9uYWwsIHNjaGVkdWxlIGNyaXRpY2FsPEJSPjxBIA0KICAgICAgaHJlZj0i aHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1pZXRmLXNpcC1zZXJ2 ZXJmZWF0dXJlcy0wMi50eHQiPmRyYWZ0LWlldGYtc2lwLXNlcnZlcmZlYXR1cmVzLTAyLnR4dDwv QT48QlI+UHJvcG9zZWQgDQogICAgICBXRyBjaGFydGVyIGl0ZW0sIHJlYWR5IGZvciBJRVNHPEJS PjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9k cmFmdC1pZXRmLXNpcC0xMDByZWwtMDAudHh0Ij5kcmFmdC1pZXRmLXNpcC0xMDByZWwtMDAudHh0 PC9BPjxCUj5Qcm9wb3NlZCANCiAgICAgIFdHIGNoYXJ0ZXIgaXRlbSwgcmV2aWV3IG9wZW4gaXNz dWVzLCBtb3ZlIHF1aWNrbHk8QlI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LnNvZnRhcm1v ci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LXJvc2VuYmVyZy1zaXAtZ3VpZGVsaW5lcy0wMC50eHQi PmRyYWZ0LXJvc2VuYmVyZy1zaXAtZ3VpZGVsaW5lcy0wMC50eHQ8L0E+PEJSPlF1ZXN0aW9uOiAN CiAgICAgIEludGVyZXN0IGluIEJDUCB0cmFjayBXRyBlZmZvcnQ/PEJSPjxBIA0KICAgICAgaHJl Zj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1yb3NlbmJlcmct c2lwLTNwY2MtMDAudHh0Ij5kcmFmdC1yb3NlbmJlcmctc2lwLTNwY2MtMDAudHh0PC9BPjxCUj50 aHJlZS1wYXJ0eSANCiAgICAgIGNhbGwgY29udHJvbCwgUXVlc3Rpb246IFdHIHRhc2s/PC9URD4N CiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIxMCUiPjEwMDA8QlI+MDozMDwvVEQ+DQogICAgPFRE IGhlaWdodD0zOCB3aWR0aD0iMjUlIj48QSANCiAgICAgIGhyZWY9Im1haWx0bzpqZHJvc2VuQGR5 bmFtaWNzb2Z0LmNvbSI+amRyb3NlbkBkeW5hbWljc29mdC5jb208L0E+PC9URD48L1RSPg0KICA8 VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5XaWxsaWFtIE1hcnNoYWxsPEJSPmFu ZCB0aGUgRENTIFRlYW08L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1JSI+PEEgDQog ICAgICBocmVmPSJodHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LWRj c2dyb3VwLXNpcC1hcmNoLTAxLnR4dCI+ZHJhZnQtZGNzZ3JvdXAtc2lwLWFyY2gtMDEudHh0PC9B PiANCiAgICAgIDxCUj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9z aXB3Zy9kcmFmdHMvZHJhZnQtZGNzZ3JvdXAtc2lwLXByaXZhY3ktMDEudHh0Ij5kcmFmdC1kY3Nn cm91cC1zaXAtcHJpdmFjeS0wMS50eHQ8L0E+IA0KICAgICAgPEJSPjxBIA0KICAgICAgaHJlZj0i aHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1kY3Nncm91cC1zaXAt c3RhdGUtMDEudHh0Ij5kcmFmdC1kY3Nncm91cC1zaXAtc3RhdGUtMDEudHh0PC9BPiANCiAgICAg IDxCUj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy9kcmFm dHMvZHJhZnQtZGNzZ3JvdXAtc2lwLWNhbGwtYXV0aC0wMS50eHQiPmRyYWZ0LWRjc2dyb3VwLXNp cC1jYWxsLWF1dGgtMDEudHh0PC9BPiANCiAgICAgIDxCUj48QSANCiAgICAgIGhyZWY9Imh0dHA6 Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtZGNzZ3JvdXAtc2lwLXByb3h5 LXByb3h5LTAxLnR4dCI+ZHJhZnQtZGNzZ3JvdXAtc2lwLXByb3h5LXByb3h5LTAxLnR4dDwvQT4g DQogICAgICA8QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy9k cmFmdHMvZHJhZnQtbWFueWZvbGtzLXNpcC1yZXNvdXJjZS0wMC50eHQiPmRyYWZ0LW1hbnlmb2xr cy1zaXAtcmVzb3VyY2UtMDAudHh0PC9BPiANCiAgICA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzgg d2lkdGg9IjEwJSI+MTAzMDxCUj4wOjQ1PC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIy NSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOnd0bUByZXNlYXJjaC5hdHQuY29tIj53dG1AcmVz ZWFyY2guYXR0LmNvbTwvQT48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgaGVpZ2h0PTM4IHdp ZHRoPSIyMCUiPkFkYW0gUm9hY2g8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1JSI+ PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2Ry YWZ0LXJvYWNoLXNpcC1zdWJzY3JpYmUtbm90aWZ5LTAwLnR4dCI+ZHJhZnQtcm9hY2gtc2lwLXN1 YnNjcmliZS1ub3RpZnktMDAudHh0PC9BPjwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0i MTAlIj4xMTE1PEJSPjA6MTA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjI1JSI+PEEg DQogICAgICBocmVmPSJtYWlsdG86YWRhbS5yb2FjaEBlcmljc3Nvbi5jb20iPmFkYW0ucm9hY2hA ZXJpY3Nzb24uY29tPC9BPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lk dGg9IjIwJSI+U2hpbmljaGkgQmFiYSA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1 JSI+ZHJhZnQtaXRzdW1vLXNpcC1tb2JpbGl0eS1yZXEtMDAudHh0PC9URD4NCiAgICA8VEQgaGVp Z2h0PTM4IHdpZHRoPSIxMCUiPjExMjU8QlI+MDo1PC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdp ZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOnNiYWJhQHRhcmkudG9zaGliYS5jb20i PnNiYWJhQHRhcmkudG9zaGliYS5jb208L0E+IDwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBo ZWlnaHQ9Mzggd2lkdGg9IjIwJSI+Q2hhaXJzPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRo PSI0NSUiPldyYXA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjEwJSI+MTEzMDwvVEQ+ DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjUlIj48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxF Pg0KPFA+Jm5ic3A7PC9QPg0KPFA+PFNUUk9ORz5UdWVzZGF5LCBNYXJjaCAyOCwgMjAwMDxCUj4x MzAwLTE1MTU8L1NUUk9ORz48L1A+DQo8VEFCTEUgYm9yZGVyPTEgaGVpZ2h0PTk0IHdpZHRoPSIx MDAlIj4NCiAgPFRCT0RZPg0KICA8VFI+DQogICAgPFREIHdpZHRoPSIyMCUiPjxTVFJPTkc+PFU+ UHJlc2VudGVyPC9VPjwvU1RST05HPjwvVEQ+DQogICAgPFREIHdpZHRoPSI0NSUiPjxTVFJPTkc+ PFU+VGl0bGU8L1U+PC9TVFJPTkc+PC9URD4NCiAgICA8VEQgd2lkdGg9IjEwJSI+PFNUUk9ORz48 VT5UaW1lPC9VPjwvU1RST05HPjwvVEQ+DQogICAgPFREIHdpZHRoPSIyNSUiPjxTVFJPTkc+PFU+ Q29udGFjdDwvVT48L1NUUk9ORz48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9IjIw JSI+Q2hhaXJzPC9URD4NCiAgICA8VEQgd2lkdGg9IjQ1JSI+SW50cm8gYW5kIEFnZW5kYTwvVEQ+ DQogICAgPFREIHdpZHRoPSIxMCUiPjEzMDA8QlI+MDowNTwvVEQ+DQogICAgPFREIHdpZHRoPSIy NSUiPmRlYW4ud2lsbGlzQHdjb20uY29tPC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdo dD0zOCB3aWR0aD0iMjAlIj5TdGV2ZSBEb25vdmFuPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdp ZHRoPSI0NSUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdn L2RyYWZ0cy9kcmFmdC1pZXRmLXNpcC1pbmZvLW1ldGhvZC0wMS50eHQiPmRyYWZ0LWlldGYtc2lw LWluZm8tbWV0aG9kLTAxLnR4dDwvQT48QlI+V0cgDQogICAgICBjaGFydGVyIGl0ZW0sIElFU0cs IGxhc3QgY2FsbCBzY2hlZHVsZWQgMy8xODxCUj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cu c29mdGFybW9yLmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtaWV0Zi1zaXAtMTgzLTAwLnR4dCI+ZHJh ZnQtaWV0Zi1zaXAtMTgzLTAwLnR4dDwvQT4gDQogICAgICAob2xkIGRyYWZ0KTxCUj5XRyBjaGFy dGVyIGl0ZW0sIHJldmlldyBzdGF0dXMsIGlzc3VlczxCUj5TY2hlZHVsZSANCiAgICAgIGNyaXRp Y2FsPEJSPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2Ry YWZ0cy9kcmFmdC1pZXRmLXNpcC1zZXNzaW9uLXRpbWVyLTAxLnR4dCI+ZHJhZnQtaWV0Zi1zaXAt c2Vzc2lvbi10aW1lci0wMS50eHQ8L0E+PEJSPlByb3Bvc2VkIA0KICAgICAgV0cgY2hhcnRlciBp dGVtLCByZXZpZXcgY2hhbmdlcywgaXNzdWVzLCBtb3ZlIHF1aWNrPC9URD4NCiAgICA8VEQgaGVp Z2h0PTM4IHdpZHRoPSIxMCUiPjEzMDU8QlI+MDoyMDwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3 aWR0aD0iMjUlIj48QSANCiAgICAgIGhyZWY9Im1haWx0bzpTdGV2ZW4uUi5Eb25vdmFuQHdjb20u Y29tIj5TdGV2ZW4uUi5Eb25vdmFuQHdjb20uY29tPC9BPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAg IDxURCBoZWlnaHQ9Mzggd2lkdGg9IjIwJSI+Um9iZXJ0IFNwYXJrczwvVEQ+DQogICAgPFREIGhl aWdodD0zOCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9y LmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtY2FtcGJlbGwtc2lwLWNjLWZyYW1ld29yay0wMC50eHQi PmRyYWZ0LWNhbXBiZWxsLXNpcC1jYy1mcmFtZXdvcmstMDAudHh0PC9BPjxCUj5XRyANCiAgICAg IENoYXJ0ZXIgSXRlbSwgU2NoZWR1bGUgQ3JpdGljYWw8QlI+PEEgDQogICAgICBocmVmPSJodHRw Oi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LXNwYXJrcy1zaXAtY2MtdHJh bnNmZXItMDAudHh0Ij5kcmFmdC1zcGFya3Mtc2lwLWNjLXRyYW5zZmVyLTAwLnR4dDwvQT48QlI+ V0cgDQogICAgICBDaGFydGVyIEl0ZW0sIFNjaGVkdWxlIENyaXRpY2FsPEJSPjxBIA0KICAgICAg aHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1jYW1wYmVs bC1zaXAtc2VydmljZS1jb250cm9sLTAwLnR4dCI+ZHJhZnQtY2FtcGJlbGwtc2lwLXNlcnZpY2Ut Y29udHJvbC0wMC50eHQ8L0E+PEJSPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJt b3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1pZXRmLXNpcC1jYWxsLWZsb3dzLTAwYS50eHQiPmRy YWZ0LWlldGYtc2lwLWNhbGwtZmxvd3MtMDBhLnR4dDwvQT48L1REPg0KICAgIDxURCBoZWlnaHQ9 Mzggd2lkdGg9IjEwJSI+MTMyNTxCUj4wOjMwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRo PSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOnJvYmVydC5zcGFya3NAd2NvbS5jb20iPnJv YmVydC5zcGFya3NAd2NvbS5jb208L0E+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdo dD0zOCB3aWR0aD0iMjAlIj5EYXZlIFdhbGtlcjwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0 aD0iNDUlIj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy9k cmFmdHMvZHJhZnQtaWV0Zi1zaXAtbWliLTAwLnR4dCI+ZHJhZnQtaWV0Zi1zaXAtbWliLTAwLnR4 dDwvQT48QlI+V0cgDQogICAgICBDaGFydGVyIGl0ZW08L1REPg0KICAgIDxURCBoZWlnaHQ9Mzgg d2lkdGg9IjEwJSI+MTM1NTxCUj4wOjE1PC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIy NSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmRyd2Fsa2VyQHNzOG5ldHdvcmtzLmNvbSI+ZHJ3 YWxrZXJAc3M4bmV0d29ya3MuY29tPC9BPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBoZWln aHQ9Mzggd2lkdGg9IjIwJSI+VEJEPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUi PlNJUC1UIFN0YXR1cyBSZXBvcnQ8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjEwJSI+ MTQxMDxCUj4wOjU8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjI1JSI+VEJEPC9URD48 L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5Hb256YWxvIENhbWFy aWxsbzwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhyZWY9 Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtY2FtYXJpbGxvLXNp cC1pc3VwLWJjcC0wMC50eHQiPmRyYWZ0LWNhbWFyaWxsby1zaXAtaXN1cC1iY3AtMDAudHh0PC9B PjxCUj5Qcm9wb3NlZCANCiAgICAgIFdHIGNoYXJ0ZXIgaXRlbT88L1REPg0KICAgIDxURCBoZWln aHQ9Mzggd2lkdGg9IjEwJSI+MTQxNTxCUj4wOjEwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdp ZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmdvbnphbG8uY2FtYXJpbGxvQGVyY2lj c3Nvbi5jb20iPmdvbnphbG8uY2FtYXJpbGxvQGVyY2ljc3Nvbi5jb208L0E+PC9URD48L1RSPg0K ICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5KYW1lcyBQb2xrPC9URD4NCiAg ICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5z b2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1wb2xrLXNpcC1tbHBwLW1hcHBpbmctMDAu dHh0Ij5kcmFmdC1wb2xrLXNpcC1tbHBwLW1hcHBpbmctMDAudHh0PC9BPjwvVEQ+DQogICAgPFRE IGhlaWdodD0zOCB3aWR0aD0iMTAlIj4xNDI1PEJSPjA6MTA8L1REPg0KICAgIDxURCBoZWlnaHQ9 Mzggd2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJtYWlsdG86am1wb2xrQGNpc2NvLmNvbSI+ am1wb2xrQGNpc2NvLmNvbTwvQT4gPC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0z OCB3aWR0aD0iMjAlIj5IZW5yeSBTaW5ucmVpY2ggPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdp ZHRoPSI0NSUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdn L2RyYWZ0cy9kcmFmdC1zaW5ucmVpY2gtc2lwLXFvcy1vc3AtMDEudHh0Ij5kcmFmdC1zaW5ucmVp Y2gtc2lwLXFvcy1vc3AtMDEudHh0PC9BPjwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0i MTAlIj4xNDM1PEJSPjA6MTA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjI1JSI+PEEg DQogICAgICBocmVmPSJtYWlsdG86aGVucnkuc2lubnJlaWNoQHdjb20uY29tIj5oZW5yeS5zaW5u cmVpY2hAd2NvbS5jb208L0E+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3 aWR0aD0iMjAlIj5Kb25hdGhhbiBSb3NlbmJlcmc8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lk dGg9IjQ1JSI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cv ZHJhZnRzL2RyYWZ0LWxlbm5veC1zaXAtcmVnLXBheWxvYWQtMDAudHh0Ij5kcmFmdC1sZW5ub3gt c2lwLXJlZy1wYXlsb2FkLTAwLnR4dDwvQT48QlI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3 LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LXJvc2VuYmVyZy1zaXAtZmlyZXdhbGxz LTAwLnR4dCI+ZHJhZnQtcm9zZW5iZXJnLXNpcC1maXJld2FsbHMtMDAudHh0PC9BPjxCUj5RdWVz dGlvbjsgDQogICAgICBJbnRlcmVzdCBpbiBpbmZvIHRyYWNrIFdHIGVmZm9ydD88QlI+PEEgDQog ICAgICBocmVmPSJodHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LXJz LXRyaXAtZ3ctMDAudHh0Ij5kcmFmdC1ycy10cmlwLWd3LTAwLnR4dDwvQT48QlI+aW50cm8gDQog ICAgICBvZiByZWxhdGVkIGRyYWZ0IGZyb20gSVBURUw8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzgg d2lkdGg9IjEwJSI+MTQ0NTxCUj4wOjMwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIy NSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmpkcm9zZW5AZHluYW1pY3NvZnQuY29tIj5qZHJv c2VuQGR5bmFtaWNzb2Z0LmNvbTwvQT48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgaGVpZ2h0 PTM4IHdpZHRoPSIyMCUiPkplZmYgTWFyayA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9 IjQ1JSI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJh ZnRzL2RyYWZ0LW1hcmstc2lwLWRtY3MtMDAudHh0Ij5kcmFmdC1tYXJrLXNpcC1kbWNzLTAwLnR4 dDwvQT48L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjEwJSI+MTUxNTxCUj4wOjEwPC9U RD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRv OltKZWZmLk1hcmtARGlhbG9naWMuY29tIj5tYWlsdG86W0plZmYuTWFya0BEaWFsb2dpYy5jb208 L0E+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5DaGFp cnM8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1JSI+V3JhcDwvVEQ+DQogICAgPFRE IGhlaWdodD0zOCB3aWR0aD0iMTAlIj4xNTI1PC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRo PSIyNSUiPmRlYW4ud2lsbGlzQHdjb20uY29tPC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT4NCjxI Uj4NCg0KPFA+UmV2aXNlZCA8IS0td2ViYm90IGJvdD0iVGltZXN0YW1wIiBTLVR5cGU9IkVESVRF RCIgUy1Gb3JtYXQ9IiVCICVkLCAlWSAlSDolTSIgc3RhcnRzcGFuIC0tPk1hcmNoIA0KMTgsIDIw MDAgMDQ6MTI8IS0td2ViYm90IGJvdD0iVGltZXN0YW1wIiBlbmRzcGFuIGktY2hlY2tzdW09IjI2 NDYzIiAtLT4gDQpHTVQ8L1A+PC9CT0RZPjwvSFRNTD4NCg== --0__=8mVGgN0Wuqy6GVJbXPsrJAthSZt3O2drdNjGyHLkq8AdjCjq9ZfTIMju-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 20:56:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24294 for ; Mon, 8 May 2000 20:56:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 64DA64450B; Mon, 8 May 2000 17:17:52 -0400 (EDT) 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 953AB44513 for ; Mon, 8 May 2000 17:05:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:10:46 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 31048443B0; Mon, 8 May 2000 14:21:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0B893443AF for ; Mon, 8 May 2000 14:21:35 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DE26952C4; Mon, 8 May 2000 14:21:34 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id C63D752B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18351 for ; Mon, 8 May 2000 06:03:34 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:59:43 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:59:41 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA114592; Mon, 8 May 2000 19:54:33 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA57526; Mon, 8 May 2000 19:59:32 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E2EE ; Mon, 8 May 2000 19:59:30 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "'Colin Perkins'" , Kimmo.Rantanen@lmf.ericsson.se Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:12 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] RE: Question on RTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --> Kimmo.Rantanen@lmf.ericsson.se writes: >I like to add one more question: >Is it absolutely necessary that both direction use the same type of >codec ? No. This is rather undesirable for vocoders or implementations employing advanced echo cancellation, intelligent jitter buffer management or a host of other DSP or voice-related properties. From my reading of the RFC, it is also equally possible for either side to chop-and-change between vocoders at any point in time (without SIP message exchange). Supporting this mixing and splicing of vocoders significantly complicates the playback engine - the ability will most likely be unsupported on simpler implementations or at best may cause small audio glitches. It would be nice if the caller could force the callee to agree on a single common vocoder if it doesn't support the use of multiple vocoders. [Making the SDP session closer to a true two-way media exchange rather than simply two disjoint vocoder packet flows in each direction.] One approach might be to place an updated SDP body in the ACK where the SDP body has only one media format selected. The RFC currently prohibits changing the SDP body in the ACK (unless the INVITE had no SDP body). Does changing the body introduce any major problems or inconsistencies ? Furthermore, IMO it would be desirable if the callee could indicate their vocoder preference by ordering the list of RTP media format values in the 183/200 response. How have other people tackled this problem ? Are there any drafts or FAQ on these subjects. Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 21:10:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24580 for ; Mon, 8 May 2000 21:10:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E3E34454F; Mon, 8 May 2000 17:18:44 -0400 (EDT) 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 EC0D944530 for ; Mon, 8 May 2000 17:17:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:23:56 EDT 2000 Received: by lists.bell-labs.com (Postfix) id EB7C5443B8; Mon, 8 May 2000 14:21:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C38BE443AF for ; Mon, 8 May 2000 14:21:40 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 099AF52BB; Mon, 8 May 2000 14:21:40 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 6B86752B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18463 for ; Mon, 8 May 2000 06:08:18 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:59:48 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:59:41 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA32126; Mon, 8 May 2000 19:54:15 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA57524; Mon, 8 May 2000 19:59:32 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E337 ; Mon, 8 May 2000 19:59:31 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Rohan Mahy Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:12 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Provisional Response Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Rohan Mahy wrote: > > Section 4.2.3 (The OPTIONS Method) goes on to say that user agents MAY > respond to OPTIONS. I would infer from this (and a quick skim of Section > 12) that there is no requirement for a proxy to respond to a method it > doesn't understand. > > Is there still any compelling reason to require the 200 OK after PRACK? Well, perhaps you should read the rest of the sentence. There are words after "MAY respond to this request". Lets be specific here. This section says: > The server is being queried as to its capabilities. A server that > believes it can contact the user, such as a user agent where the user > is logged in and has been recently active, MAY respond to this > request with a capability set. A called user agent MAY return a > status reflecting how it would have responded to an invitation, e.g., > > > > > Handley, et al. Standards Track [Page 29] > > RFC 2543 SIP: Session Initiation Protocol March 1999 > > > 600 (Busy). Such a server SHOULD return an Allow header field > indicating the methods that it supports. Proxy and redirect servers > simply forward the request without indicating their capabilities. > > This method MUST be supported by SIP proxy, redirect and user agent > servers, registrars and clients. That is it MAY respond with a capability set, or MAY respond with a status reflecting how it would have responded to the invitation. The MAY is a choice among how the response is formulated, NOT on whether a response is sent. All requests are responded to. period. By not having the 200 OK to PRACK, we break the transactional model of the protocol. This means proxies and UAs have all this extra state laying around. It means spurious CANCELs and responses might get sent. It means we probably need a Proxy-Require, and I really don't want to do that, because it means compatibility is broken. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 21:33:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24961 for ; Mon, 8 May 2000 21:33:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 67376443EA; Mon, 8 May 2000 15:34:21 -0400 (EDT) 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 5E8AA443EF for ; Mon, 8 May 2000 15:33:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:38:38 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A105344376; Mon, 8 May 2000 14:20:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 359834436A for ; Mon, 8 May 2000 14:20:14 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 48D5252AB; Mon, 8 May 2000 14:20:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 7ADA852D5 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20405 for ; Mon, 8 May 2000 08:10:22 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:57:06 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:57:04 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA156728; Mon, 8 May 2000 21:51:37 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA31338; Mon, 8 May 2000 21:56:53 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00419F4F ; Mon, 8 May 2000 21:56:46 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "Adam B. Roach" Cc: iptel@lists.research.bell-labs.com, sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:21 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] RE: URL Generalization for Portability (was TRIP) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Adam wrote: > Dean blurted > >Something like > > > > INVITE premiumservice@gateway.carrier.com > > To: tel:5551212;trans=lnp?gdbs > > > >could be used to indicate to gateway.carrier.com that premium gateway > >service is requested towards the PSTN location identified by telephone > >number 5551212, that LNP and GDBS translation have been applied, and that > >the phone number is of local scope for the gateway. > > Since the To: field isn't allowed to change during the transaction, > aren't you going to run into problems if some service along the way > determines that the called number needs to change (as the result of > LNP, 800/900 lookup, etc)? Right you are. That should teach me not to come up with examples while squatting on one of those interminable telco conference calls. But I still think using a tel: url gives a cleaner semantic than sip:number@gateway;user=phone. I was talking with some guys today about scope and context, and I'm inclined to think we need the nature of address and numbering plan indicator fields out of some ISUP variants. Scope appears to be global, local, or private, with some need to represent local and private within some context like area code or private numbering plan. So, for example tel:+19727294162 is a global number with unspecified context, tel:9727294162 is a local number tel:7724162;phone-context=mcivnet34 is a private number with context in the MCI private numbering plan #34 tel:4512345687724162;phone-context=mciswtrunk is a private number, in numbering plan 45, relative to switch 123 and trunk group 45678 . . . and whatever other sick private variants one might come up with -- Dean --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 21:42:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25007 for ; Mon, 8 May 2000 21:42:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C50A4443D; Mon, 8 May 2000 16:03:29 -0400 (EDT) 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 9BC5044440 for ; Mon, 8 May 2000 15:59:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:04:57 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E13B14437F; Mon, 8 May 2000 14:20:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7CEB84437D for ; Mon, 8 May 2000 14:20:25 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C552E52C8; Mon, 8 May 2000 14:20:24 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id E7CF852B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20262 for ; Mon, 8 May 2000 08:06:02 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 07:58:48 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:58:45 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA137628; Mon, 8 May 2000 21:53:20 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA42218; Mon, 8 May 2000 21:58:37 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041C884 ; Mon, 8 May 2000 21:58:31 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "Mark D. Foster" Cc: "'John Mainwaring'" , iptel@lists.research.bell-labs.com, "'James Yu'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:25 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: TRIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Mark Foster wrote: > That at least some forms of Iptel must comply with the non-reliance requirement in at least some countries suggests that the > SIP, TRIP, enum, etc., must be flexible enough to allow implementations that will satisfy these requirements, and still be > interoperable with those that don't. > > In the US and Canada, the key to this was the N-1 trigger placement policy. This was simply a guideline on which networks > should be prepared to dip calls placed to which areas in order to not force calls to be re-routed at the donor network > (termination routing). Key to having flexibility on where triggers are placed, resulting in NPDB queries, is having a form of > post-query signaling that makes the query results available to all downstream networks. I'm not really sure that the N-1 concept works that well in an IP environment: 1. If you look at DNS as a similar service to LNP on the IP side, the originating host does a name to address translation right away. This happens even if the name thats being translated is "far away". This avoids triangle routing, as has been discussed. 2. The interconnection of SIP servers and providers within the IP world is not that rigid. I'm not sure how a SIP proxy would indeed determine that it is the N-1th server in the chain. In any case, determination of where the NPDB query is done is something I don't think is within the scope of iptel to determine. All we need to figure out is what kind of numbers are distributed in TRIP. Near as I can tell, since LRNs still refer to the prefix of numbers served by a switch, doing what we were doing all along works just fine. > > The key data elements in ANSI ISUP are: the LNP-query-done indicator (bit in the FCI); placing a routing number returned > from the NPDB in the CdPN (LRN or whatever), and moving the original dialed number to a GAP. Subsequent call routing is > done on the routing number, while not loosing the dialed portable subscriber number. Given the need for SIP to interoperate > with ANSI ISUP, there should be some consideration of implementing these semantics. > > If SIP captured these fields, so as to provide a post-dip form of downstream signaling, and TRIP were designed to build route > tables based on administratively assigned number ranges (which, by definition would make calls to routing numbers [LRN] > routable) , and enum did not require DNS queries to be answered by donor networks, then the existing regulatory > requirements for LNP could be met. First off, SIP has two fields that identify the destination party. The To field represents the original number that the caller called, and the request URI represents the address translated at each hop. Thus, the To field carries the original dialed number, and the request URI would carrying the routing number. Now, do we need to somehow indicate that the LNP dip has been done? I'm still unsure about that. I believe Henning had suggested that the use of a sip URL (as opposed to a tel URL) in the request URI would effectively be an indicator of such. That aside, I think there is a possible confusion if one were to assume an LRN looked like a normal SIP URL: INVITE sip:1212344 SIP/2.0 To: sip:14081234567 The problem is related to past discussions on the SIP mailing list regarding overlap dialing. A terminating gateway would look at sip:1212344, and know how to route it, but might not know whether this was a dialed number with more digits coming, or an LRN. Does it matter? Not being an ISUP expert, I'm not sure. If it does matter, something like user=lrn within the SIP URL would fix that. But anyway, thats also not a problem for iptel, although I've cc'd the sip list on this message. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 21:43:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25018 for ; Mon, 8 May 2000 21:43:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 15268443E1; Mon, 8 May 2000 16:40:23 -0400 (EDT) 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 EEAC244482 for ; Mon, 8 May 2000 16:39:55 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:44:25 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2AFBE44398; Mon, 8 May 2000 14:21:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 05D5144396 for ; Mon, 8 May 2000 14:21:18 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3745952C4; Mon, 8 May 2000 14:21:17 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id C70AE52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18519 for ; Mon, 8 May 2000 06:10:23 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:16 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:58:14 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA141826; Mon, 8 May 2000 19:53:06 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA57332; Mon, 8 May 2000 19:58:05 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036C12F ; Mon, 8 May 2000 19:58:03 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Bryan Byerly Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:05 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: How to put a Kerberos ticket in SIP messages? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Another option is just a SIP MIME bodypart. No binary-to-text translation needed there. Would be nice to spec this topic out. -- 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 May 8 22:02:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26222 for ; Mon, 8 May 2000 22:02:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC24544443; Mon, 8 May 2000 16:03:07 -0400 (EDT) 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 D9FD94443D for ; Mon, 8 May 2000 15:59:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:04:57 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0843044380; Mon, 8 May 2000 14:20:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BD7CB44365 for ; Mon, 8 May 2000 14:20:56 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D830752C4; Mon, 8 May 2000 14:20:55 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 2766F52B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20386 for ; Mon, 8 May 2000 08:09:39 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:57:02 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:57:01 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA228744; Mon, 8 May 2000 21:51:53 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA31334; Mon, 8 May 2000 21:56:52 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041A02A ; Mon, 8 May 2000 21:56:48 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Robert.Sparks@wcom.com Cc: "'Henning Schulzrinne'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:22 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Comments on transfer draft (sparks-sip-cc-transfer-00) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Robert Sparks wrote: > > > Why? I really liked the idea of knowing that this call was > > the result of > > a transfer, and knowing who the transferor was. A UA can always ignore > > this information, and then get the basic service you have today. > > I really like the idea too. Perhaps as part of the work right now we > can capture knowing that the call was the result of a transfer (by adding > an informational header to the invite - something that doesn't change > the invite semantics), but my preference is to wait for direction from > the SIP security task folks before addressing telling the transfer target > who the transferor was. There isn't going to be any magic poof that causes a solution to be generated. I think its the job of the author of the extension to propose some security mechanism so that there can be a starting point for discussion. > > > The document says TRANSFER can't have a body. Why not? I can think of > > some cool uses for this down the road. Why rule it out? > > For consistency of implementation? (btw - One of those cool uses could be > providing the identity of the transferor.) The presence of a body > would likely affect the semantics of the operation (if it were honored, > hence the consistency comment) through side-effects if not directly, > so would it not make sense for the addition of a body to the base > method be an actual extention? The presence of a body should not, in any way, alter the basic semantics of the request. Treatment of a body in TRANSFER is no different than bodies in any other request. If the UAS doesn't know what to do with it, it sends a 415. If it does know what to do with it, it gets processed. > > This thing about the Call-ID being copied from the TRANSFER > > seemed odd. > > Why is that? If you wanted to accomplish this, it seems better to have > > the URL in the Transfer-To header contain the Call-ID as a URL > > parameter. In other words, why not do: > > > > Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays > > Interesing thought! Can we explore your thinking more here? > Using this, the TRANSFER would look like > > TRANSFER sip:transferee@transfereehost > Transfer-To: sip:transfer-target@targethost?Call-ID=abc@eeOrorhost > Call-ID: abc@eeOrorhost > > Are you suggesting the subsequent invite look like this? > > INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost > Call-ID: def@eehost No, like this: INVITE sip:transfer-target@targethost Call-ID: abc@ee0rorhost This way, the tranferror could ask the transferred party to add other headers or even body elements. > On reflection, I specified this copy because it resulted in > a call-leg tuple that looked the same as it would have after > a sip-cc-01 blind transfer. The motivation that draft had for > this behavior may not apply here. Is there any value in keeping > the Call-ID information accross this function (thinking of it > as PLEASEINVITE instead of TRANSFER)? Perhaps. By allowing the Call-ID to be used to be placed in the URL in the Transfer-To header, the transferror can make the call-id the same, different, or unspecified. This seems to result in maximum flexibility. Later, Henning Schulzrinne writes: > > > > It would be really nice, however, to know ahead of time whether all > > parties supported transfer (and any other mechanisms to be defined). The > > Supported extension draft defines a way in which the UAC would indicate > > to the UAS that it knows the new mechanism, but that draft does not > > mandate that a UAS return a Supported header in the response to any > > method (only OPTIONS). We can add this, and say that if a UAS receives a > > request (with any method) with a Supported header, it should place a > > Supported header in the response and list those features it knows. This > > would allow a caller to know whether the called party supports transfer > > before trying it. Thoughts? > > It might make sense to have both Allow and Supported in responses other > than OPTIONS. In this case, Allow seems the more appropriate solution, > given that it's a new method and that having two mechanisms to ask for > the same thing seems a bad design. You're right, its Allow here, not Supported. > Thus, suggesting that final responses > include Allow doesn't break anything (a UAC could have a simple logic > that did "if response didn't have Allow, send an OPTIONS just in case"), > but it does cut down on traffic. It's much nicer if the UAC can gray out > a Transfer button rather than pop up a failure note after the caller has > said "let me transfer you...". Definitely. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 22:20:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26402 for ; Mon, 8 May 2000 22:20:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3889A44485; Mon, 8 May 2000 16:40:31 -0400 (EDT) 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 63B214448D for ; Mon, 8 May 2000 16:39:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 16:44:26 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7509C4439B; Mon, 8 May 2000 14:21:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3B1794439A for ; Mon, 8 May 2000 14:21:20 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D63E152BB; Mon, 8 May 2000 14:21:18 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id EC90B52D0 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18308 for ; Mon, 8 May 2000 06:02:18 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:59:38 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:59:38 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA113792; Mon, 8 May 2000 19:54:30 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA63678; Mon, 8 May 2000 19:59:29 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E07E ; Mon, 8 May 2000 19:59:24 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Anoop Tripathi Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:14 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Why must a stateless proxy insert a Via header for itself. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Anoop Tripathi wrote: > > Currently, the RFC states that every server in the path of a request must add > itself as a Via header. > > As a stateless proxy, if this restriction is removed then I can process more > calls with faster call setup times. > > So , can we make inserting itself as a Via optional for a stateless proxy. > > Thanks, > > Anoop Then how do you do loop detection ?? -- Best regards, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 22:24:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26459 for ; Mon, 8 May 2000 22:24:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C400444BA; Mon, 8 May 2000 16:27:36 -0400 (EDT) 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 C9A6944496 for ; Mon, 8 May 2000 16:25:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:31:15 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E2DEB4438C; Mon, 8 May 2000 14:21:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id AC3A644383 for ; Mon, 8 May 2000 14:21:07 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D204952B6; Mon, 8 May 2000 14:21:06 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id F2AC152BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20347 for ; Mon, 8 May 2000 08:08:15 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 08:01:36 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 08:01:32 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA206994; Mon, 8 May 2000 21:56:25 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA51864; Mon, 8 May 2000 22:01:24 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00420691 ; Mon, 8 May 2000 22:01:10 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "'Jonathan Rosenberg'" Cc: "Mark D. Foster" , iptel@lists.research.bell-labs.com, "'James Yu'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:33 +0530 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=BUF29doZf2yUWjbIm7tcLWLKnm22jaukyq7ojT7Y2WSvmhDmIwa69e10" Content-Disposition: inline Subject: [SIP] RE: TRIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --0__=BUF29doZf2yUWjbIm7tcLWLKnm22jaukyq7ojT7Y2WSvmhDmIwa69e10 Content-type: text/plain; charset=us-ascii Content-Disposition: inline |-----Original Message----- |From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] | |> John Mainwaring wrote: |> |> |The problem is related to past discussions on the SIP mailing list |> |regarding overlap dialing. A terminating gateway would look at |> |sip:1212344, and know how to route it, but might not know whether |> this |> |was a dialed number with more digits coming, or an LRN. Does it |> matter? |> |Not being an ISUP expert, I'm not sure. If it does matter, something |> |like user=lrn within the SIP URL would fix that. |> |> user=lrn is almost right. If you have queried a portable number and |> found that it is not ported, then the DN has the same status |as an LRN |> would have if the number were ported (i.e. it should be treated as |> authoritative for routing). user=np-queried might be closer to the |> mark. | |I wonder if we can't think about this problem in more general terms. | |In the SIP model, each proxy owns some piece of the namespace |(engineering.dynamicsoft.com, for example), and is therefore |responsible |for the definition of the user space (jdrosen@) within that domain. |Thats why each proxy can, an usually will, perform some kind of URI |translation independent from other proxies. Our underlying assumption |was that usernames only have meaning within their domain. For example, |with sip:jdrosen@dynamicsoft.com, only a dynamicsoft.com proxy |knows how |to handle jdrosen. There might be jdrosen's in other domains |that aren't |me. However, in the case of telephone numbers, the proxy that owns the |domain does not necessarily own the user space. |sip:5551212@gateway.com, |for example, uses a user name that is not "owned" by |gateway.com, in the |sense that this name has valid semantics outside of gateway.com. Other |domains, like wcom.com, would know how to handle this number as well. |Its possible that we might even see things besides phone |numbers as user |names that are valid across multiple domains. An example is (heaven |forbid), social security numbers (in the US, at least): | |sip:123-45-6789@wcom.com;user=ssn | |Now, I might imagine that some kind of mobility services might be |supplied for these names, so they might need to be translated also. | |I'll call these type of user names "cross domain user names". | |With cross domain user names, this is where we run into issues |like "has |the number been queried yet". However, I think we might see other |translation mechanisms besides LNP. Soooo, might it not be useful to |define URI parameters that indicate what global translation services |have been applied to a cross domain user name? | |As an example: | |sip:15551212@cisco.com;user=phone;trans="lnp,gdbs" | |where lnp and gdbs are some kind of global translation services that |apply to names of the type phone. | |For cross domain user names, we will always need a URI parameter to |indicate the global namespace from which these names are drawn. In the |case of phone numbers, thats user=phone. Our original intent with the |user=phone parameter was to specify only the type of BNF used for the |user part of the URI. But, the more general operation of |specifying both |the format and the namespace seems useful. I think the problem is a bit different. 919-555-1212 uniquely identifies a user within the North American Numbering Plan. It's just that with LNP it can no longer locate the user. If someone wants to use 919-555-1212@vanity.org as an email address and someone else uses 919-555-1212@workplace.com, that's fine, but has nothing to do with telephone numbers. I think I want to be able to place a call when all I know is 919-555-1212. Without LNP, it would have been fairly easy to discover that 919-555 implied bellsouth, so the number could have been given as 919-555-1212@bellsouth.com. Now it is possible that some numbers from 919-555 might be ported to othertel.com. Othertel might the native owner of 919-444-xxxx numbers and might choose to host 919-555-1313 on their 919-444 exchange. In that case, the LRN for 919-555-1313 would be 919-444. Once I have done an LNP query, I might want to use something like 919-555-1212@919-555.bellsouth.com for a number that has not been ported and 919-555-1313@919-444.othertel.com for a number that has been ported to othertel. I can't shorten the 10 digit number in the user name, because of things like NPA overlays and switches that host multiple office codes. I need the full address to select the right user as well as the LRN to route to the right place. If a SIP user wants to call someone who uses a PSTN phone, the system needs to deal with certain inconvenient aspects of the PSTN. A notation like 919-555-1212@919-555 or 919-555-1313@919-444 might be useful to indicate that an LNP query has been done, and that authoritative routing information is now available. Appending text-based names such as 919-555-1212@919-555@onetel.com or 919-555-1313@919-444@anothertel.com might even allow subsequent routing to take place without further concessions to PSTN quirkiness. Of course this system could also be expanded to mobility services; routing for 919-555-1313 could be set to 212-666-1414@212-666.bigappletel.com in the daytime and 919-555-1313@919-444.othertel.com in the evening if you went in for that kind of commuting. |> It's also necessary to define what the TRIP should do differently |> depending on whether the np-queried indication is present. I must |> admit I came into this discussion mainly because I have worked on |> LNP. I assume the objective is not to route unqueried calls to the |> donor proxy. | |Hmm. This is something thats also different from the PSTN. The cost of |routing to the donor proxy in SIP is much less, since proxies can be |stateless. Thus, if a proxy receives a call for some number that is |ported, it stateless proxies the call towards the next destination. The |result is that there is no triangle routing for media (there generally |isn't), nor for subsequent signaling. There is only marginal cost for |the donor provider. There are obviously polticial and business issues; |one may not want to trust or rely upon the donor proxy at all, |as is the |case of LNP in the US. But, the general SIP model is that we assume |proxies do route calls; no security measures can prevent a proxy from |dropping messages. Why, in the case of LNP, do we now need to assume |these proxies won't route calls? | | | | | I have noted that originator query may not be practical |> for nationwide calling and that donor proxy is too late unless you're |> prepared to consider RTP. | |The assumption of the impractability of originator queries has |everything to do with the existing structure of LNP. Its |mainly because, |AFAIK, the systems are different all over the world. However, if we use |the IP model, with a DNS solution, its no harder to query for a number |on the other side of the planet as it would be for a number next door. No, it's not quite as simple as that. The system is designed around the strengths and weaknesses of the PSTN. The the architecture of the pstn makes it easy to route calls on partial information, but switches in the pstn perform better if they do as few database queries as possible. Switches work fine if they have no idea of the portability status of most numbers; they are only set up to query nearby numbers. A switch doesn't need authoritative data that a number is not portable. It just needs to be set up to query that (local) subset of portable numbers which it would misroute if it didn't query them. The LNP databases are distributed because of the geographic restrictions on Bell Operating Companies. Each RBOC only has to worry about its own data, and only has to route queries within its own SS7 signalling network. There are actually two levels of database, the SCPs that actually handle queries and the NPAC (?) which processes administrative change requests and downloads the SCPs. There could be several SCPs owned by different operating companies that contain the same data; each operating company would route queries to its own SCP. The NPAC service is provided by NeuStar, formerly Lockheed Martin, and Mark Foster of Neustar has given us some excellent information on LNP within this thread. It seems unlikely that IP telephony would use the existing SCPs for queries, or that it would be based on SS7 TCAP messaging. I don't have a clear idea of what databases there would be for IP telephony, but they would certainly have to arrange to download data from the NPAC. There are costs associated with the databases and with keeping the LNP information up to date. If you want to do source routing, it will certainly take a non-trivial effort to make North American or even world wide LNP information accessible. There would be a case for aggregating it with whatever centralized routing servers there are, or for arranging for the destination's proxy to return information about ported numbers instead of simply refusing the invitation. |Also, pardon my ignorance, but what is RTP? Many of us on this |list know |RTP as the Real Time Transport Protocol (rfc1889) but I don't think |thats what you mean. In that context, RTP = Release To Pivot; switch A routes a call to switch B which may provide some service and then releases the call back to A (the pivot switch) with instructions to reroute the call to destination C. Sorry, I thought I had expanded it earlier. Is there any TLA in our businsess that only has one expansion? What does TLA mean apart from Three Letter Acronym? | One answer might be for the TRIP to provide |> a response on unqueried numbers that routes to an intermediate server |> that does know how to do NP queries for the destination DN. | |TRIP is not a query protocol. Its a routing protocol. This would be a |SIP function, and is already possible. "408 Not Found". But why was it not found? In the telephony e.164 numbering domain prior to LNP, "not found" meant "does not exist". LNP required switches to add "might be somewhere else" logic. It would be desirable for a routing agent to say something more informative than "not found", if it had any additional information. --0__=BUF29doZf2yUWjbIm7tcLWLKnm22jaukyq7ojT7Y2WSvmhDmIwa69e10 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBOQU1FPSJHZW5lcmF0b3IiIENPTlRF TlQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJzaW9uIDUuNS4yNDQ4LjAiPg0KPFRJVExFPlJFOiBU UklQPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpF PTI+fC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58 RnJvbTogSm9uYXRoYW4gUm9zZW5iZXJnIFs8QSBIUkVGPSJtYWlsdG86amRyb3NlbkBkeW5hbWlj c29mdC5jb20iPm1haWx0bzpqZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbTwvQT5dPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj58PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0OyBKb2huIE1haW53 YXJpbmcgd3JvdGU6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0OyA8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPnwmZ3Q7IHxUaGUgcHJvYmxlbSBpcyByZWxhdGVkIHRvIHBhc3QgZGlzY3Vz c2lvbnMgb24gdGhlIFNJUCBtYWlsaW5nIGxpc3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnwm Z3Q7IHxyZWdhcmRpbmcgb3ZlcmxhcCBkaWFsaW5nLiBBIHRlcm1pbmF0aW5nIGdhdGV3YXkgd291 bGQgbG9vayBhdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fCZndDsgfHNpcDoxMjEyMzQ0LCBh bmQga25vdyBob3cgdG8gcm91dGUgaXQsIGJ1dCBtaWdodCBub3Qga25vdyB3aGV0aGVyPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0OyB0aGlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58 Jmd0OyB8d2FzIGEgZGlhbGVkIG51bWJlciB3aXRoIG1vcmUgZGlnaXRzIGNvbWluZywgb3IgYW4g TFJOLiBEb2VzIGl0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0OyBtYXR0ZXI/PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0OyB8Tm90IGJlaW5nIGFuIElTVVAgZXhwZXJ0LCBJJ20g bm90IHN1cmUuIElmIGl0IGRvZXMgbWF0dGVyLCBzb21ldGhpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPnwmZ3Q7IHxsaWtlIHVzZXI9bHJuIHdpdGhpbiB0aGUgU0lQIFVSTCB3b3VsZCBmaXgg dGhhdC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnwmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+fCZndDsgdXNlcj1scm4gaXMgYWxtb3N0IHJpZ2h0LiZuYnNwOyBJZiB5b3UgaGF2ZSBx dWVyaWVkIGEgcG9ydGFibGUgbnVtYmVyIGFuZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fCZn dDsgZm91bmQgdGhhdCBpdCBpcyBub3QgcG9ydGVkLCB0aGVuIHRoZSBETiBoYXMgdGhlIHNhbWUg c3RhdHVzIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fGFzIGFuIExSTjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+fCZndDsgd291bGQgaGF2ZSBpZiB0aGUgbnVtYmVyIHdlcmUgcG9ydGVkIChp LmUuIGl0IHNob3VsZCBiZSB0cmVhdGVkIGFzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0 OyBhdXRob3JpdGF0aXZlIGZvciByb3V0aW5nKS4mbmJzcDsgdXNlcj1ucC1xdWVyaWVkIG1pZ2h0 IGJlIGNsb3NlciB0byB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnwmZ3Q7IG1hcmsuPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj58PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58SSB3b25k ZXIgaWYgd2UgY2FuJ3QgdGhpbmsgYWJvdXQgdGhpcyBwcm9ibGVtIGluIG1vcmUgZ2VuZXJhbCB0 ZXJtcy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PnxJbiB0aGUgU0lQIG1vZGVsLCBlYWNoIHByb3h5IG93bnMgc29tZSBwaWVjZSBvZiB0aGUgbmFt ZXNwYWNlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58KGVuZ2luZWVyaW5nLmR5bmFtaWNzb2Z0 LmNvbSwgZm9yIGV4YW1wbGUpLCBhbmQgaXMgdGhlcmVmb3JlIDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+fHJlc3BvbnNpYmxlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Zm9yIHRoZSBkZWZp bml0aW9uIG9mIHRoZSB1c2VyIHNwYWNlIChqZHJvc2VuQCkgd2l0aGluIHRoYXQgZG9tYWluLjwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fFRoYXRzIHdoeSBlYWNoIHByb3h5IGNhbiwgYW4gdXN1 YWxseSB3aWxsLCBwZXJmb3JtIHNvbWUga2luZCBvZiBVUkk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPnx0cmFuc2xhdGlvbiBpbmRlcGVuZGVudCBmcm9tIG90aGVyIHByb3hpZXMuIE91ciB1bmRl cmx5aW5nIGFzc3VtcHRpb248L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnx3YXMgdGhhdCB1c2Vy bmFtZXMgb25seSBoYXZlIG1lYW5pbmcgd2l0aGluIHRoZWlyIGRvbWFpbi4gRm9yIGV4YW1wbGUs PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58d2l0aCBzaXA6amRyb3NlbkBkeW5hbWljc29mdC5j b20sIG9ubHkgYSBkeW5hbWljc29mdC5jb20gcHJveHkgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj58a25vd3MgaG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58dG8gaGFuZGxlIGpkcm9zZW4u IFRoZXJlIG1pZ2h0IGJlIGpkcm9zZW4ncyBpbiBvdGhlciBkb21haW5zIDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+fHRoYXQgYXJlbid0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58bWUuIEhv d2V2ZXIsIGluIHRoZSBjYXNlIG9mIHRlbGVwaG9uZSBudW1iZXJzLCB0aGUgcHJveHkgdGhhdCBv d25zIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fGRvbWFpbiBkb2VzIG5vdCBuZWNlc3Nh cmlseSBvd24gdGhlIHVzZXIgc3BhY2UuIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fHNpcDo1 NTUxMjEyQGdhdGV3YXkuY29tLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fGZvciBleGFtcGxl LCB1c2VzIGEgdXNlciBuYW1lIHRoYXQgaXMgbm90ICZxdW90O293bmVkJnF1b3Q7IGJ5IDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+fGdhdGV3YXkuY29tLCBpbiB0aGU8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPnxzZW5zZSB0aGF0IHRoaXMgbmFtZSBoYXMgdmFsaWQgc2VtYW50aWNzIG91dHNp ZGUgb2YgZ2F0ZXdheS5jb20uIE90aGVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58ZG9tYWlu cywgbGlrZSB3Y29tLmNvbSwgd291bGQga25vdyBob3cgdG8gaGFuZGxlIHRoaXMgbnVtYmVyIGFz IHdlbGwuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58SXRzIHBvc3NpYmxlIHRoYXQgd2UgbWln aHQgZXZlbiBzZWUgdGhpbmdzIGJlc2lkZXMgcGhvbmUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj58bnVtYmVycyBhcyB1c2VyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58bmFtZXMgdGhhdCBh cmUgdmFsaWQgYWNyb3NzIG11bHRpcGxlIGRvbWFpbnMuIEFuIGV4YW1wbGUgaXMgKGhlYXZlbjwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fGZvcmJpZCksIHNvY2lhbCBzZWN1cml0eSBudW1iZXJz IChpbiB0aGUgVVMsIGF0IGxlYXN0KTo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnw8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPnxzaXA6MTIzLTQ1LTY3ODlAd2NvbS5jb207dXNlcj1zc248L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPnw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnxOb3csIEkg bWlnaHQgaW1hZ2luZSB0aGF0IHNvbWUga2luZCBvZiBtb2JpbGl0eSBzZXJ2aWNlcyBtaWdodCBi ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fHN1cHBsaWVkIGZvciB0aGVzZSBuYW1lcywgc28g dGhleSBtaWdodCBuZWVkIHRvIGJlIHRyYW5zbGF0ZWQgYWxzby48L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPnw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnxJJ2xsIGNhbGwgdGhlc2UgdHlwZSBv ZiB1c2VyIG5hbWVzICZxdW90O2Nyb3NzIGRvbWFpbiB1c2VyIG5hbWVzJnF1b3Q7LjwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+fDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fFdpdGggY3Jvc3Mg ZG9tYWluIHVzZXIgbmFtZXMsIHRoaXMgaXMgd2hlcmUgd2UgcnVuIGludG8gaXNzdWVzIDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+fGxpa2UgJnF1b3Q7aGFzPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj58dGhlIG51bWJlciBiZWVuIHF1ZXJpZWQgeWV0JnF1b3Q7LiBIb3dldmVyLCBJIHRoaW5r IHdlIG1pZ2h0IHNlZSBvdGhlcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fHRyYW5zbGF0aW9u IG1lY2hhbmlzbXMgYmVzaWRlcyBMTlAuIFNvb29vLCBtaWdodCBpdCBub3QgYmUgdXNlZnVsIHRv PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58ZGVmaW5lIFVSSSBwYXJhbWV0ZXJzIHRoYXQgaW5k aWNhdGUgd2hhdCBnbG9iYWwgdHJhbnNsYXRpb24gc2VydmljZXM8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPnxoYXZlIGJlZW4gYXBwbGllZCB0byBhIGNyb3NzIGRvbWFpbiB1c2VyIG5hbWU/PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj58PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58QXMgYW4g ZXhhbXBsZTo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPnxzaXA6MTU1NTEyMTJAY2lzY28uY29tO3VzZXI9cGhvbmU7dHJhbnM9JnF1b3Q7bG5wLGdk YnMmcXVvdDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPnx3aGVyZSBsbnAgYW5kIGdkYnMgYXJlIHNvbWUga2luZCBvZiBnbG9iYWwgdHJhbnNsYXRp b24gc2VydmljZXMgdGhhdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fGFwcGx5IHRvIG5hbWVz IG9mIHRoZSB0eXBlIHBob25lLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+fEZvciBjcm9zcyBkb21haW4gdXNlciBuYW1lcywgd2Ugd2lsbCBhbHdh eXMgbmVlZCBhIFVSSSBwYXJhbWV0ZXIgdG88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnxpbmRp Y2F0ZSB0aGUgZ2xvYmFsIG5hbWVzcGFjZSBmcm9tIHdoaWNoIHRoZXNlIG5hbWVzIGFyZSBkcmF3 bi4gSW4gdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Y2FzZSBvZiBwaG9uZSBudW1iZXJz LCB0aGF0cyB1c2VyPXBob25lLiBPdXIgb3JpZ2luYWwgaW50ZW50IHdpdGggdGhlPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj58dXNlcj1waG9uZSBwYXJhbWV0ZXIgd2FzIHRvIHNwZWNpZnkgb25s eSB0aGUgdHlwZSBvZiBCTkYgdXNlZCBmb3IgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58 dXNlciBwYXJ0IG9mIHRoZSBVUkkuIEJ1dCwgdGhlIG1vcmUgZ2VuZXJhbCBvcGVyYXRpb24gb2Yg PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58c3BlY2lmeWluZyBib3RoPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj58dGhlIGZvcm1hdCBhbmQgdGhlIG5hbWVzcGFjZSBzZWVtcyB1c2VmdWwuPC9G T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SSB0aGluayB0aGUgcHJvYmxlbSBpcyBhIGJp dCBkaWZmZXJlbnQuJm5ic3A7IDkxOS01NTUtMTIxMiB1bmlxdWVseSBpZGVudGlmaWVzIGEgdXNl ciB3aXRoaW4gdGhlIE5vcnRoIEFtZXJpY2FuIE51bWJlcmluZyBQbGFuLiZuYnNwOyBJdCdzIGp1 c3QgdGhhdCB3aXRoIExOUCBpdCBjYW4gbm8gbG9uZ2VyIGxvY2F0ZSB0aGUgdXNlci4mbmJzcDsg SWYgc29tZW9uZSB3YW50cyB0byB1c2UgOTE5LTU1NS0xMjEyQHZhbml0eS5vcmcgYXMgYW4gZW1h aWwgYWRkcmVzcyBhbmQgc29tZW9uZSBlbHNlIHVzZXMgOTE5LTU1NS0xMjEyQHdvcmtwbGFjZS5j b20sIHRoYXQncyBmaW5lLCBidXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0ZWxlcGhvbmUgbnVt YmVycy4mbmJzcDsgSSB0aGluayBJIHdhbnQgdG8gYmUgYWJsZSB0byBwbGFjZSBhIGNhbGwgd2hl biBhbGwgSSBrbm93IGlzIDkxOS01NTUtMTIxMi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpF PTI+V2l0aG91dCBMTlAsIGl0IHdvdWxkIGhhdmUgYmVlbiBmYWlybHkgZWFzeSB0byZuYnNwOyBk aXNjb3ZlciB0aGF0IDkxOS01NTUgaW1wbGllZCBiZWxsc291dGgsIHNvIHRoZSBudW1iZXIgY291 bGQgaGF2ZSBiZWVuIGdpdmVuIGFzIDkxOS01NTUtMTIxMkBiZWxsc291dGguY29tLiZuYnNwOyBO b3cgaXQgaXMgcG9zc2libGUgdGhhdCBzb21lIG51bWJlcnMgZnJvbSA5MTktNTU1IG1pZ2h0IGJl IHBvcnRlZCB0byBvdGhlcnRlbC5jb20uJm5ic3A7IE90aGVydGVsIG1pZ2h0IHRoZSBuYXRpdmUg b3duZXIgb2YgOTE5LTQ0NC14eHh4IG51bWJlcnMgYW5kIG1pZ2h0IGNob29zZSB0byBob3N0IDkx OS01NTUtMTMxMyBvbiB0aGVpciA5MTktNDQ0IGV4Y2hhbmdlLiZuYnNwOyBJbiB0aGF0IGNhc2Us IHRoZSBMUk4gZm9yIDkxOS01NTUtMTMxMyB3b3VsZCBiZSA5MTktNDQ0LiZuYnNwOyBPbmNlIEkg aGF2ZSBkb25lIGFuIExOUCBxdWVyeSwgSSBtaWdodCB3YW50IHRvIHVzZSBzb21ldGhpbmcgbGlr ZSA5MTktNTU1LTEyMTJAOTE5LTU1NS5iZWxsc291dGguY29tIGZvciBhIG51bWJlciB0aGF0IGhh cyBub3QgYmVlbiBwb3J0ZWQgYW5kJm5ic3A7IDkxOS01NTUtMTMxM0A5MTktNDQ0Lm90aGVydGVs LmNvbSBmb3IgYSBudW1iZXIgdGhhdCBoYXMgYmVlbiBwb3J0ZWQgdG8gb3RoZXJ0ZWwuPC9GT05U PjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgY2FuJ3Qgc2hvcnRlbiB0aGUgMTAgZGlnaXQgbnVt YmVyIGluIHRoZSB1c2VyIG5hbWUsIGJlY2F1c2Ugb2YgdGhpbmdzIGxpa2UgTlBBIG92ZXJsYXlz IGFuZCBzd2l0Y2hlcyB0aGF0IGhvc3QgbXVsdGlwbGUgb2ZmaWNlIGNvZGVzLiZuYnNwOyBJIG5l ZWQgdGhlIGZ1bGwgYWRkcmVzcyB0byBzZWxlY3QgdGhlIHJpZ2h0IHVzZXIgYXMgd2VsbCBhcyB0 aGUgTFJOIHRvIHJvdXRlIHRvIHRoZSByaWdodCBwbGFjZS4gPC9GT05UPjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPklmIGEgU0lQIHVzZXIgd2FudHMgdG8gY2FsbCBzb21lb25lIHdobyB1c2VzIGEg UFNUTiBwaG9uZSwgdGhlIHN5c3RlbSBuZWVkcyB0byBkZWFsIHdpdGggY2VydGFpbiBpbmNvbnZl bmllbnQgYXNwZWN0cyBvZiB0aGUgUFNUTi4gQSBub3RhdGlvbiBsaWtlIDkxOS01NTUtMTIxMkA5 MTktNTU1IG9yIDkxOS01NTUtMTMxM0A5MTktNDQ0IG1pZ2h0IGJlIHVzZWZ1bCB0byBpbmRpY2F0 ZSB0aGF0IGFuIExOUCBxdWVyeSBoYXMgYmVlbiBkb25lLCBhbmQgdGhhdCBhdXRob3JpdGF0aXZl IHJvdXRpbmcgaW5mb3JtYXRpb24gaXMgbm93IGF2YWlsYWJsZS4mbmJzcDsgQXBwZW5kaW5nIHRl eHQtYmFzZWQgbmFtZXMgc3VjaCBhcyA5MTktNTU1LTEyMTJAOTE5LTU1NUBvbmV0ZWwuY29tIG9y IDkxOS01NTUtMTMxM0A5MTktNDQ0QGFub3RoZXJ0ZWwuY29tIG1pZ2h0IGV2ZW4gYWxsb3cgc3Vi c2VxdWVudCByb3V0aW5nIHRvIHRha2UgcGxhY2Ugd2l0aG91dCBmdXJ0aGVyIGNvbmNlc3Npb25z IHRvIFBTVE4gcXVpcmtpbmVzcy48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+T2YgY291 cnNlIHRoaXMgc3lzdGVtIGNvdWxkIGFsc28gYmUgZXhwYW5kZWQgdG8gbW9iaWxpdHkgc2Vydmlj ZXM7IHJvdXRpbmcgZm9yIDkxOS01NTUtMTMxMyBjb3VsZCBiZSBzZXQgdG8gMjEyLTY2Ni0xNDE0 QDIxMi02NjYuYmlnYXBwbGV0ZWwuY29tIGluIHRoZSBkYXl0aW1lIGFuZCA5MTktNTU1LTEzMTNA OTE5LTQ0NC5vdGhlcnRlbC5jb20gaW4gdGhlIGV2ZW5pbmcgaWYgeW91IHdlbnQgaW4gZm9yIHRo YXQga2luZCBvZiBjb21tdXRpbmcuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPnwmZ3Q7 IEl0J3MgYWxzbyBuZWNlc3NhcnkgdG8gZGVmaW5lIHdoYXQgdGhlIFRSSVAgc2hvdWxkIGRvIGRp ZmZlcmVudGx5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0OyBkZXBlbmRpbmcgb24gd2hl dGhlciB0aGUgbnAtcXVlcmllZCBpbmRpY2F0aW9uIGlzIHByZXNlbnQuJm5ic3A7IEkgbXVzdDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fCZndDsgYWRtaXQgSSBjYW1lIGludG8gdGhpcyBkaXNj dXNzaW9uIG1haW5seSBiZWNhdXNlIEkgaGF2ZSB3b3JrZWQgb248L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPnwmZ3Q7IExOUC4mbmJzcDsgSSBhc3N1bWUgdGhlIG9iamVjdGl2ZSBpcyBub3QgdG8g cm91dGUgdW5xdWVyaWVkIGNhbGxzIHRvIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fCZn dDsgZG9ub3IgcHJveHkuIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+fEhtbS4gVGhpcyBpcyBzb21ldGhpbmcgdGhhdHMgYWxzbyBkaWZmZXJlbnQg ZnJvbSB0aGUgUFNUTi4gVGhlIGNvc3Qgb2Y8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnxyb3V0 aW5nIHRvIHRoZSBkb25vciBwcm94eSBpbiBTSVAgaXMgbXVjaCBsZXNzLCBzaW5jZSBwcm94aWVz IGNhbiBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fHN0YXRlbGVzcy4gVGh1cywgaWYgYSBw cm94eSByZWNlaXZlcyBhIGNhbGwgZm9yIHNvbWUgbnVtYmVyIHRoYXQgaXM8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPnxwb3J0ZWQsIGl0IHN0YXRlbGVzcyBwcm94aWVzIHRoZSBjYWxsIHRvd2Fy ZHMgdGhlIG5leHQgZGVzdGluYXRpb24uIFRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fHJl c3VsdCBpcyB0aGF0IHRoZXJlIGlzIG5vIHRyaWFuZ2xlIHJvdXRpbmcgZm9yIG1lZGlhICh0aGVy ZSBnZW5lcmFsbHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnxpc24ndCksIG5vciBmb3Igc3Vi c2VxdWVudCBzaWduYWxpbmcuIFRoZXJlIGlzIG9ubHkgbWFyZ2luYWwgY29zdCBmb3I8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPnx0aGUgZG9ub3IgcHJvdmlkZXIuIFRoZXJlIGFyZSBvYnZpb3Vz bHkgcG9sdGljaWFsIGFuZCBidXNpbmVzcyBpc3N1ZXM7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj58b25lIG1heSBub3Qgd2FudCB0byB0cnVzdCBvciByZWx5IHVwb24gdGhlIGRvbm9yIHByb3h5 IGF0IGFsbCwgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58YXMgaXMgdGhlPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj58Y2FzZSBvZiBMTlAgaW4gdGhlIFVTLiBCdXQsIHRoZSBnZW5lcmFsIFNJ UCBtb2RlbCBpcyB0aGF0IHdlIGFzc3VtZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fHByb3hp ZXMgZG8gcm91dGUgY2FsbHM7IG5vIHNlY3VyaXR5IG1lYXN1cmVzIGNhbiBwcmV2ZW50IGEgcHJv eHkgZnJvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fGRyb3BwaW5nIG1lc3NhZ2VzLiBXaHks IGluIHRoZSBjYXNlIG9mIExOUCwgZG8gd2Ugbm93IG5lZWQgdG8gYXNzdW1lPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj58dGhlc2UgcHJveGllcyB3b24ndCByb3V0ZSBjYWxscz88L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPnw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnw8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPnw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnw8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPnwgSSBoYXZlIG5vdGVkIHRoYXQgb3JpZ2luYXRvciBxdWVyeSBtYXkgbm90IGJl IHByYWN0aWNhbDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fCZndDsgZm9yIG5hdGlvbndpZGUg Y2FsbGluZyBhbmQgdGhhdCBkb25vciBwcm94eSBpcyB0b28gbGF0ZSB1bmxlc3MgeW91J3JlPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0OyBwcmVwYXJlZCB0byBjb25zaWRlciBSVFAuIDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+fFRoZSBh c3N1bXB0aW9uIG9mIHRoZSBpbXByYWN0YWJpbGl0eSBvZiBvcmlnaW5hdG9yIHF1ZXJpZXMgaGFz PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58ZXZlcnl0aGluZyB0byBkbyB3aXRoIHRoZSBleGlz dGluZyBzdHJ1Y3R1cmUgb2YgTE5QLiBJdHMgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58bWFp bmx5IGJlY2F1c2UsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58QUZBSUssIHRoZSBzeXN0ZW1z IGFyZSBkaWZmZXJlbnQgYWxsIG92ZXIgdGhlIHdvcmxkLiBIb3dldmVyLCBpZiB3ZSB1c2U8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPnx0aGUgSVAgbW9kZWwsIHdpdGggYSBETlMgc29sdXRpb24s IGl0cyBubyBoYXJkZXIgdG8gcXVlcnkgZm9yIGEgbnVtYmVyPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj58b24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldCBhcyBpdCB3b3VsZCBiZSBmb3Ig YSBudW1iZXIgbmV4dCBkb29yLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPk5vLCBp dCdzIG5vdCBxdWl0ZSBhcyBzaW1wbGUgYXMgdGhhdC4mbmJzcDsgVGhlIHN5c3RlbSBpcyBkZXNp Z25lZCBhcm91bmQgdGhlIHN0cmVuZ3RocyBhbmQgd2Vha25lc3NlcyBvZiB0aGUgUFNUTi4mbmJz cDsgVGhlIHRoZSBhcmNoaXRlY3R1cmUgb2YgdGhlIHBzdG4gbWFrZXMgaXQgZWFzeSB0byByb3V0 ZSBjYWxscyBvbiBwYXJ0aWFsIGluZm9ybWF0aW9uLCBidXQgc3dpdGNoZXMgaW4gdGhlIHBzdG4g cGVyZm9ybSBiZXR0ZXIgaWYgdGhleSBkbyBhcyBmZXcgZGF0YWJhc2UgcXVlcmllcyBhcyBwb3Nz aWJsZS4mbmJzcDsgU3dpdGNoZXMgd29yayBmaW5lIGlmIHRoZXkgaGF2ZSBubyBpZGVhIG9mIHRo ZSBwb3J0YWJpbGl0eSBzdGF0dXMgb2YgbW9zdCBudW1iZXJzOyB0aGV5IGFyZSBvbmx5IHNldCB1 cCB0byBxdWVyeSBuZWFyYnkgbnVtYmVycy4mbmJzcDsgQSBzd2l0Y2ggZG9lc24ndCBuZWVkIGF1 dGhvcml0YXRpdmUgZGF0YSB0aGF0IGEgbnVtYmVyIGlzIG5vdCBwb3J0YWJsZS4mbmJzcDsgSXQg anVzdCBuZWVkcyB0byBiZSBzZXQgdXAgdG8gcXVlcnkgdGhhdCAobG9jYWwpIHN1YnNldCBvZiBw b3J0YWJsZSBudW1iZXJzIHdoaWNoIGl0IHdvdWxkIG1pc3JvdXRlIGlmIGl0IGRpZG4ndCBxdWVy eSB0aGVtLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGUgTE5QIGRhdGFiYXNlcyBh cmUgZGlzdHJpYnV0ZWQgYmVjYXVzZSBvZiB0aGUgZ2VvZ3JhcGhpYyByZXN0cmljdGlvbnMgb24g QmVsbCBPcGVyYXRpbmcgQ29tcGFuaWVzLiZuYnNwOyBFYWNoIFJCT0Mgb25seSBoYXMgdG8gd29y cnkgYWJvdXQgaXRzIG93biBkYXRhLCBhbmQgb25seSBoYXMgdG8gcm91dGUgcXVlcmllcyB3aXRo aW4gaXRzIG93biBTUzcgc2lnbmFsbGluZyBuZXR3b3JrLjwvRk9OVD48L1A+DQoNCjxQPjxGT05U IFNJWkU9Mj5UaGVyZSBhcmUgYWN0dWFsbHkgdHdvIGxldmVscyBvZiBkYXRhYmFzZSwgdGhlIFND UHMgdGhhdCBhY3R1YWxseSBoYW5kbGUgcXVlcmllcyBhbmQgdGhlIE5QQUMgKD8pIHdoaWNoIHBy b2Nlc3NlcyBhZG1pbmlzdHJhdGl2ZSBjaGFuZ2UgcmVxdWVzdHMgYW5kIGRvd25sb2FkcyB0aGUg U0NQcy4mbmJzcDsgVGhlcmUgY291bGQgYmUgc2V2ZXJhbCBTQ1BzIG93bmVkIGJ5IGRpZmZlcmVu dCBvcGVyYXRpbmcgY29tcGFuaWVzIHRoYXQgY29udGFpbiB0aGUgc2FtZSBkYXRhOyBlYWNoIG9w ZXJhdGluZyBjb21wYW55IHdvdWxkIHJvdXRlIHF1ZXJpZXMgdG8gaXRzIG93biBTQ1AuJm5ic3A7 IFRoZSBOUEFDIHNlcnZpY2UgaXMgcHJvdmlkZWQgYnkgTmV1U3RhciwgZm9ybWVybHkgTG9ja2hl ZWQgTWFydGluLCBhbmQgTWFyayBGb3N0ZXIgb2YgTmV1c3RhciBoYXMgZ2l2ZW4gdXMgc29tZSBl eGNlbGxlbnQgaW5mb3JtYXRpb24gb24gTE5QIHdpdGhpbiB0aGlzIHRocmVhZC48L0ZPTlQ+PC9Q Pg0KDQo8UD48Rk9OVCBTSVpFPTI+SXQgc2VlbXMgdW5saWtlbHkgdGhhdCBJUCB0ZWxlcGhvbnkg d291bGQgdXNlIHRoZSBleGlzdGluZyBTQ1BzIGZvciBxdWVyaWVzLCBvciB0aGF0IGl0IHdvdWxk IGJlIGJhc2VkIG9uIFNTNyBUQ0FQIG1lc3NhZ2luZy4mbmJzcDsgSSBkb24ndCBoYXZlIGEgY2xl YXIgaWRlYSBvZiB3aGF0IGRhdGFiYXNlcyB0aGVyZSB3b3VsZCBiZSBmb3IgSVAgdGVsZXBob255 LCBidXQgdGhleSB3b3VsZCBjZXJ0YWlubHkgaGF2ZSB0byBhcnJhbmdlIHRvIGRvd25sb2FkIGRh dGEgZnJvbSB0aGUgTlBBQy4mbmJzcDsgVGhlcmUgYXJlIGNvc3RzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgZGF0YWJhc2VzIGFuZCB3aXRoIGtlZXBpbmcgdGhlIExOUCBpbmZvcm1hdGlvbiB1cCB0byBk YXRlLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JZiB5b3Ugd2FudCB0byBkbyBzb3Vy Y2Ugcm91dGluZywgaXQgd2lsbCBjZXJ0YWlubHkgdGFrZSBhIG5vbi10cml2aWFsIGVmZm9ydCB0 byBtYWtlIE5vcnRoIEFtZXJpY2FuIG9yIGV2ZW4gd29ybGQgd2lkZSBMTlAgaW5mb3JtYXRpb24g YWNjZXNzaWJsZS4mbmJzcDsgVGhlcmUgd291bGQgYmUgYSBjYXNlIGZvciBhZ2dyZWdhdGluZyBp dCB3aXRoIHdoYXRldmVyIGNlbnRyYWxpemVkIHJvdXRpbmcgc2VydmVycyB0aGVyZSBhcmUsIG9y IGZvciBhcnJhbmdpbmcgZm9yIHRoZSBkZXN0aW5hdGlvbidzIHByb3h5IHRvIHJldHVybiBpbmZv cm1hdGlvbiBhYm91dCBwb3J0ZWQgbnVtYmVycyBpbnN0ZWFkIG9mIHNpbXBseSByZWZ1c2luZyB0 aGUgaW52aXRhdGlvbi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+fEFsc28sIHBhcmRv biBteSBpZ25vcmFuY2UsIGJ1dCB3aGF0IGlzIFJUUD8gTWFueSBvZiB1cyBvbiB0aGlzIDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+fGxpc3Qga25vdzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ fFJUUCBhcyB0aGUgUmVhbCBUaW1lIFRyYW5zcG9ydCBQcm90b2NvbCAocmZjMTg4OSkgYnV0IEkg ZG9uJ3QgdGhpbms8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnx0aGF0cyB3aGF0IHlvdSBtZWFu LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkluIHRoYXQgY29udGV4dCwgUlRQID0g UmVsZWFzZSBUbyBQaXZvdDsgc3dpdGNoIEEgcm91dGVzIGEgY2FsbCB0byBzd2l0Y2ggQiB3aGlj aCBtYXkgcHJvdmlkZSBzb21lIHNlcnZpY2UgYW5kIHRoZW4gcmVsZWFzZXMgdGhlIGNhbGwgYmFj ayB0byBBICh0aGUgcGl2b3Qgc3dpdGNoKSB3aXRoIGluc3RydWN0aW9ucyB0byByZXJvdXRlIHRo ZSBjYWxsIHRvIGRlc3RpbmF0aW9uIEMuJm5ic3A7IFNvcnJ5LCBJIHRob3VnaHQgSSBoYWQgZXhw YW5kZWQgaXQgZWFybGllci48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SXMgdGhlcmUg YW55IFRMQSBpbiBvdXIgYnVzaW5zZXNzIHRoYXQgb25seSBoYXMgb25lIGV4cGFuc2lvbj8mbmJz cDsgV2hhdCBkb2VzIFRMQSBtZWFuIGFwYXJ0IGZyb20gVGhyZWUgTGV0dGVyIEFjcm9ueW0/PC9G T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+fCBPbmUgYW5zd2VyIG1pZ2h0IGJlIGZvciB0 aGUgVFJJUCB0byBwcm92aWRlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58Jmd0OyBhIHJlc3Bv bnNlIG9uIHVucXVlcmllZCBudW1iZXJzIHRoYXQgcm91dGVzIHRvIGFuIGludGVybWVkaWF0ZSBz ZXJ2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnwmZ3Q7IHRoYXQgZG9lcyBrbm93IGhvdyB0 byBkbyBOUCBxdWVyaWVzIGZvciB0aGUgZGVzdGluYXRpb24gRE4uPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj58PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj58VFJJUCBpcyBub3QgYSBxdWVyeSBw cm90b2NvbC4gSXRzIGEgcm91dGluZyBwcm90b2NvbC4gVGhpcyB3b3VsZCBiZSBhPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj58U0lQIGZ1bmN0aW9uLCBhbmQgaXMgYWxyZWFkeSBwb3NzaWJsZS4g JnF1b3Q7NDA4IE5vdCBGb3VuZCZxdW90Oy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj5CdXQgd2h5IHdhcyBpdCBub3QgZm91bmQ/Jm5ic3A7IEluIHRoZSB0ZWxlcGhvbnkgZS4xNjQg bnVtYmVyaW5nIGRvbWFpbiBwcmlvciB0byBMTlAsICZxdW90O25vdCBmb3VuZCZxdW90OyBtZWFu dCAmcXVvdDtkb2VzIG5vdCBleGlzdCZxdW90Oy4mbmJzcDsgTE5QIHJlcXVpcmVkIHN3aXRjaGVz IHRvIGFkZCAmcXVvdDttaWdodCBiZSBzb21ld2hlcmUgZWxzZSZxdW90OyBsb2dpYy4mbmJzcDsg SXQgd291bGQgYmUgZGVzaXJhYmxlIGZvciBhIHJvdXRpbmcgYWdlbnQgdG8gc2F5IHNvbWV0aGlu ZyBtb3JlIGluZm9ybWF0aXZlIHRoYW4gJnF1b3Q7bm90IGZvdW5kJnF1b3Q7LCBpZiZuYnNwOyBp dCBoYWQgYW55IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uPC9GT05UPjwvUD4NCg0KPC9CT0RZPg0K PC9IVE1MPg0K --0__=BUF29doZf2yUWjbIm7tcLWLKnm22jaukyq7ojT7Y2WSvmhDmIwa69e10-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 22:29:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26544 for ; Mon, 8 May 2000 22:29:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A2C9443B5; Mon, 8 May 2000 15:20:31 -0400 (EDT) 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 17CB8443B7 for ; Mon, 8 May 2000 15:19:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:25:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9C9EA4434D; Mon, 8 May 2000 14:20:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 323944435E for ; Mon, 8 May 2000 14:20:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 58DE152E2; Mon, 8 May 2000 14:19:58 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 9826152E3 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20225 for ; Mon, 8 May 2000 08:04:52 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:57:54 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:57:53 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA27760; Mon, 8 May 2000 21:52:27 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA42500; Mon, 8 May 2000 21:57:44 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041B597 ; Mon, 8 May 2000 21:57:43 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "Liess, Laura" Cc: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:28 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: uploading services from the user's home network to a sip server of the visited network within a 3G.IP environement Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com "Liess, Laura" wrote: > > Hi, > > after doing a very good job by deciding to take SIP for call control for multimedia services within 3G.IP >networks, the 3G.IP operators have a lot of open items concerning the architecture, one of them being which >network controls the services for a roaming user: the home network, the visited network or shared control. >The concrete question: how can I upload at the begin or during the call the roamimg user's services >available in the home network into the SIP proxy of the visited network? As far as I know, the CPL and >REGISTER helps me to upload services only from the UA to the proxy. I'm not an expert in wireless, so I'm not certain of the scope of the services we are talking about. Mid call services, for example, are not currently within the scope of CPL. However, there is nothing which prevents the CPL-upload-in-register mechanism from being used by a server to upload scripts to another server. Registrations, in general, can be used for third party controls. The From field identifies the party initiating the registration. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 22:37:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27615 for ; Mon, 8 May 2000 22:37:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9311D4452E; Mon, 8 May 2000 17:18:40 -0400 (EDT) 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 408414452F for ; Mon, 8 May 2000 17:17:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:23:56 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 35D86443B7; Mon, 8 May 2000 14:21:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E6B98443AF for ; Mon, 8 May 2000 14:21:39 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 55CEA52AB; Mon, 8 May 2000 14:21:39 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id A424952BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18364 for ; Mon, 8 May 2000 06:04:15 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 05:59:49 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:59:44 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA34410; Mon, 8 May 2000 19:54:14 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA63680; Mon, 8 May 2000 19:59:30 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E02C ; Mon, 8 May 2000 19:59:23 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: dean.willis@wcom.com (Dean Willis) Cc: jdrosen@dynamicsoft.com, crm312a@nortelnetworks.com, mark.foster@npac.com, iptel@lists.research.bell-labs.com, james.yu@neustar.com, sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:14 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: URL Generalization for Portability (was TRIP) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >There was some discussion of this problem wrt DCS during the November >interim meeting. It was suggested that a cross-domain destination which is a >phone number could be better represented by a tel: URL than by confusing the >scope of the user part of a sip: URL. This simplilifies life greatly. > >Something like > > INVITE premiumservice@gateway.carrier.com > To: tel:5551212;trans=lnp?gdbs > >could be used to indicate to gateway.carrier.com that premium gateway >service is requested towards the PSTN location identified by telephone >number 5551212, that LNP and GDBS translation have been applied, and that >the phone number is of local scope for the gateway. Since the To: field isn't allowed to change during the transaction, aren't you going to run into problems if some service along the way determines that the called number needs to change (as the result of LNP, 800/900 lookup, etc)? For example; let's say that one of the services that I have out in the network is a "reachable from anywhere" speed dialing list. It maps, for example, "4" as a telephone number to "2145551212". So I launch an invite to my local proxy: INVITE sip:4@proxy.spleen.com SIP/2.0 To: tel:4 It goes through my service node: INVITE sip:4@usersvc-34987.spleen.com SIP/2.0 To: tel:4 And he wants to send it on to your gateway for premium service, after translating the 4 into "2145551212." It's my interpretation that, under the model you're proposing, I'd need to send along INVITE sip:premiumservice@gateway.carrier.com SIP/2.0 To: tel:2145551212 But that would break the transaction, since the To: field has changed. I understand the distinction between destination and service activation that you're trying to make, but your example seems unworkable. What am I missing? -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 22:39:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27701 for ; Mon, 8 May 2000 22:39:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 916E144449; Mon, 8 May 2000 16:27:03 -0400 (EDT) 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 97DD344431 for ; Mon, 8 May 2000 16:25:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 16:31:15 EDT 2000 Received: by lists.bell-labs.com (Postfix) id CFC724438D; Mon, 8 May 2000 14:21:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id A0E3F44383 for ; Mon, 8 May 2000 14:21:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DCAC052BB; Mon, 8 May 2000 14:21:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id EAC2652C4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id HAA19871 for ; Mon, 8 May 2000 07:57:32 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:54:24 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:54:22 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA57508; Mon, 8 May 2000 21:48:57 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA68540; Mon, 8 May 2000 21:54:13 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00416102 ; Mon, 8 May 2000 21:54:06 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Anoop Tripathi Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:14 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Why must a stateless proxy insert a Via header for itself. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Anoop Tripathi wrote: > > Currently, the RFC states that every server in the path of a request must add > itself as a Via header. > > As a stateless proxy, if this restriction is removed then I can process more > calls with faster call setup times. > > So , can we make inserting itself as a Via optional for a stateless proxy. > > Thanks, > > Anoop Then how do you do loop detection ?? -- Best regards, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 22:41:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27863 for ; Mon, 8 May 2000 22:41:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F085D44487; Mon, 8 May 2000 16:14:28 -0400 (EDT) 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 ECD2744466 for ; Mon, 8 May 2000 16:13:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:18:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9FE7A44385; Mon, 8 May 2000 14:21:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7113844383 for ; Mon, 8 May 2000 14:21:00 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CF84F52C4; Mon, 8 May 2000 14:20:59 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 30DCF52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20183 for ; Mon, 8 May 2000 08:03:36 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:57:57 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:57:54 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA201206 for ; Mon, 8 May 2000 21:52:47 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA21080 for ; Mon, 8 May 2000 21:57:46 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041B4EF ; Mon, 8 May 2000 21:57:41 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Sip list Message-ID: Date: Mon, 8 May 2000 14:10:28 +0530 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=Ou6T7DhQ2m4mKDGzeYRejw2B1bdvsusIxIxnOuTTiRmLq4eAc1mroHn6" Content-Disposition: inline Subject: [SIP] Re: Billing SIP proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --0__=Ou6T7DhQ2m4mKDGzeYRejw2B1bdvsusIxIxnOuTTiRmLq4eAc1mroHn6 Content-type: text/plain; charset=us-ascii Content-Disposition: inline David, David Oran wrote: > >The question is: is it posible to define, to any extent, a mechanism > capable >of preventing the "hacked" terminal to bypass the proxy and > call > the >"standard" endpoints witout being billed ? > > There's no way to prevent one "hacked terminal" from talking to > another > "hacked terminal" directly, bypassing any proxy. > Fine, this is just impossible to prevent. Then, I had in mind some via-header based solutions but, eventually, I managed to hack all of them. It looks like the one you propose requires some more thinking..... > You can, at some pain, protect against is having a "standard terminal" > > answer a call from a "hacked terminal". The way you do this is when a > SIP > message comes into the UAC, ou look at the last VIA on the via list. > You > then get the IP address of that machine (either because it was on the > VIA > istelf or you called DNS to get its address) and compare that with the > > source address of the SIP message. I assume you mean "Source address of the IP packet containing the SIP message", right ? > If they don't match, you know somebody is > trying to spoof you. mmm, let me think.... got it !?!?!? * 1) what if there' s a NAT in between ? * 2) vhat if the proxy "must be in the list", but not necessarily as the last one ? (E.g. because the proxy that bills you is that of your "home network", and you have moved somewhere else) * 2) on the other hand, if you want the billing proxy always to be the last one (apart from all the clearinghouse-related issues Henry was mentioning today), it must be communicated upon registration. I must think about this, but I have the feeling that a possibility might be that I can fool the "standard" terminal to re-register with me (the hacked terminal) making him believe I am "the proxy". I would obviously be adding my address to the VIA header when inviting him. * 3) I will think a little bit more about it * 4) Anyway, do yo agree with me that the complexity of the "crack" required to "patch" such features on the "standard" terminal (going back therefore to the first case you mentioned) is definetly much smaller than that of installing a complete protocol from scratch on a device that was not designed to run it ? Thank you very much and Best Regards Giuseppe > > If they DO match, then if the SIP UAC knows the list of SIP proxies > which it > trusts to deliver calls (and bill for them), the UAC either accepts or > > rejects the request appropriately. > > > Please CC replies to gricagni@tin.it (it is easier for me to read > email > from > such mailbox here in Adelaide) > > >Please let me know > >Best Regards > >Giuseppe --0__=Ou6T7DhQ2m4mKDGzeYRejw2B1bdvsusIxIxnOuTTiRmLq4eAc1mroHn6 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KRGF2aWQsDQo8cD5EYXZpZCBPcmFuIHdyb3RlOg0KPGJsb2NrcXVvdGUg VFlQRT1DSVRFPj5UaGUgcXVlc3Rpb24gaXM6IGlzIGl0IHBvc2libGUgdG8gZGVmaW5lLCB0byBh bnkNCmV4dGVudCwgYSBtZWNoYW5pc20NCjxicj5jYXBhYmxlID5vZiBwcmV2ZW50aW5nIHRoZSAi aGFja2VkIiB0ZXJtaW5hbCB0byBieXBhc3MgdGhlIHByb3h5IGFuZA0KY2FsbA0KPGJyPnRoZSA+ InN0YW5kYXJkIiBlbmRwb2ludHMgd2l0b3V0IGJlaW5nIGJpbGxlZCA/DQo8cD5UaGVyZSdzIG5v IHdheSB0byBwcmV2ZW50IG9uZSAiaGFja2VkIHRlcm1pbmFsIiBmcm9tIHRhbGtpbmcgdG8gYW5v dGhlcg0KPGJyPiJoYWNrZWQgdGVybWluYWwiIGRpcmVjdGx5LCBieXBhc3NpbmcgYW55IHByb3h5 Lg0KPGJyPiZuYnNwOzwvYmxvY2txdW90ZT4NCkZpbmUsIHRoaXMgaXMganVzdCBpbXBvc3NpYmxl IHRvIHByZXZlbnQuDQo8cD5UaGVuLCBJIGhhZCBpbiBtaW5kIHNvbWUgdmlhLWhlYWRlciBiYXNl ZCBzb2x1dGlvbnMgYnV0LCBldmVudHVhbGx5LA0KSSBtYW5hZ2VkIHRvIGhhY2sgYWxsIG9mIHRo ZW0uIEl0IGxvb2tzIGxpa2UgdGhlIG9uZSB5b3UgcHJvcG9zZSByZXF1aXJlcw0Kc29tZSBtb3Jl IHRoaW5raW5nLi4uLi4NCjxibG9ja3F1b3RlIFRZUEU9Q0lURT5Zb3UgY2FuLCBhdCBzb21lIHBh aW4sIHByb3RlY3QgYWdhaW5zdCBpcyBoYXZpbmcNCmEgInN0YW5kYXJkIHRlcm1pbmFsIg0KPGJy PmFuc3dlciBhIGNhbGwgZnJvbSBhICJoYWNrZWQgdGVybWluYWwiLiBUaGUgd2F5IHlvdSBkbyB0 aGlzIGlzIHdoZW4NCmEgU0lQDQo8YnI+bWVzc2FnZSBjb21lcyBpbnRvIHRoZSBVQUMsIG91IGxv b2sgYXQgdGhlIGxhc3QgVklBIG9uIHRoZSB2aWEgbGlzdC4NCllvdQ0KPGJyPnRoZW4gZ2V0IHRo ZSBJUCBhZGRyZXNzIG9mIHRoYXQgbWFjaGluZSAoZWl0aGVyIGJlY2F1c2UgaXQgd2FzIG9uIHRo ZQ0KVklBDQo8YnI+aXN0ZWxmIG9yIHlvdSBjYWxsZWQgRE5TIHRvIGdldCBpdHMgYWRkcmVzcykg YW5kIGNvbXBhcmUgdGhhdCB3aXRoDQp0aGUNCjxicj5zb3VyY2UgYWRkcmVzcyBvZiB0aGUgU0lQ IG1lc3NhZ2UuPC9ibG9ja3F1b3RlPg0KSSBhc3N1bWUgeW91IG1lYW4gIlNvdXJjZSBhZGRyZXNz IG9mIHRoZSBJUCBwYWNrZXQgY29udGFpbmluZyB0aGUgU0lQIG1lc3NhZ2UiLA0KcmlnaHQgPw0K PGJsb2NrcXVvdGUgVFlQRT1DSVRFPklmIHRoZXkgZG9uJ3QgbWF0Y2gsIHlvdSBrbm93IHNvbWVi b2R5IGlzDQo8YnI+dHJ5aW5nIHRvIHNwb29mIHlvdS48L2Jsb2NrcXVvdGU+DQptbW0sIGxldCBt ZSB0aGluay4uLi4NCjxwPmdvdCBpdCAhPyE/IT8NCjx1bD4NCjxsaT4NCjEpIHdoYXQgaWYgdGhl cmUnIHMgYSBOQVQgaW4gYmV0d2VlbiA/PC9saT4NCjwvdWw+DQoNCjx1bD4NCjxsaT4NCjIpIHZo YXQgaWYgdGhlIHByb3h5ICJtdXN0IGJlIGluIHRoZSBsaXN0IiwgYnV0IG5vdCBuZWNlc3Nhcmls eSBhcyZuYnNwOw0KdGhlIGxhc3Qgb25lID8gKEUuZy4gYmVjYXVzZSB0aGUgcHJveHkgdGhhdCBi aWxscyB5b3UgaXMgdGhhdCBvZiB5b3VyICJob21lDQpuZXR3b3JrIiwgYW5kIHlvdSBoYXZlIG1v dmVkIHNvbWV3aGVyZSBlbHNlKTwvbGk+DQo8L3VsPg0KDQo8dWw+DQo8bGk+DQoyKSBvbiB0aGUg b3RoZXIgaGFuZCwgaWYgeW91Jm5ic3A7IHdhbnQgdGhlIGJpbGxpbmcgcHJveHkgYWx3YXlzIHRv IGJlDQp0aGUgbGFzdCBvbmUgKGFwYXJ0IGZyb20gYWxsIHRoZSBjbGVhcmluZ2hvdXNlLXJlbGF0 ZWQgaXNzdWVzIEhlbnJ5IHdhcw0KbWVudGlvbmluZyB0b2RheSksIGl0IG11c3QgYmUgY29tbXVu aWNhdGVkIHVwb24gcmVnaXN0cmF0aW9uLiBJIG11c3QgdGhpbmsNCmFib3V0IHRoaXMsIGJ1dCBJ IGhhdmUgdGhlIGZlZWxpbmcgdGhhdCBhIHBvc3NpYmlsaXR5IG1pZ2h0IGJlIHRoYXQmbmJzcDsN CkkgY2FuIGZvb2wgdGhlICJzdGFuZGFyZCIgdGVybWluYWwgdG8gcmUtcmVnaXN0ZXIgd2l0aCBt ZSAodGhlIGhhY2tlZCB0ZXJtaW5hbCkNCm1ha2luZyBoaW0gYmVsaWV2ZSBJIGFtICJ0aGUgcHJv eHkiLiBJIHdvdWxkIG9idmlvdXNseSBiZSBhZGRpbmcgbXkgYWRkcmVzcw0KdG8gdGhlIFZJQSBo ZWFkZXIgd2hlbiBpbnZpdGluZyBoaW0uPC9saT4NCjwvdWw+DQoNCjx1bD4NCjxsaT4NCjMpIEkg d2lsbCB0aGluayBhIGxpdHRsZSBiaXQgbW9yZSBhYm91dCBpdDwvbGk+DQo8L3VsPg0KDQo8dWw+ DQo8bGk+DQo0KSBBbnl3YXksIGRvIHlvIGFncmVlIHdpdGggbWUgdGhhdCB0aGUgY29tcGxleGl0 eSBvZiB0aGUgImNyYWNrIiByZXF1aXJlZA0KdG8gInBhdGNoIiBzdWNoIGZlYXR1cmVzIG9uIHRo ZSAic3RhbmRhcmQiIHRlcm1pbmFsIChnb2luZyBiYWNrIHRoZXJlZm9yZQ0KdG8gdGhlIGZpcnN0 IGNhc2UgeW91IG1lbnRpb25lZCkgaXMgZGVmaW5ldGx5IG11Y2ggc21hbGxlciB0aGFuIHRoYXQg b2YNCmluc3RhbGxpbmcgYSBjb21wbGV0ZSBwcm90b2NvbCBmcm9tIHNjcmF0Y2ggb24gYSBkZXZp Y2UgdGhhdCB3YXMgbm90IGRlc2lnbmVkDQp0byBydW4gaXQgPzwvbGk+DQo8L3VsPg0KDQo8cD48 YnI+VGhhbmsgeW91IHZlcnkgbXVjaCBhbmQNCjxicj5CZXN0IFJlZ2FyZHMNCjxicj5HaXVzZXBw ZQ0KPGJsb2NrcXVvdGUgVFlQRT1DSVRFPiZuYnNwOw0KPGJyPklmIHRoZXkgRE8gbWF0Y2gsIHRo ZW4gaWYgdGhlIFNJUCBVQUMga25vd3MgdGhlIGxpc3Qgb2YgU0lQIHByb3hpZXMNCndoaWNoIGl0 DQo8YnI+dHJ1c3RzIHRvIGRlbGl2ZXIgY2FsbHMgKGFuZCBiaWxsIGZvciB0aGVtKSwgdGhlIFVB QyBlaXRoZXIgYWNjZXB0cw0Kb3INCjxicj5yZWplY3RzIHRoZSByZXF1ZXN0IGFwcHJvcHJpYXRl bHkuDQo8cD4+IFBsZWFzZSBDQyByZXBsaWVzIHRvIGdyaWNhZ25pQHRpbi5pdCAoaXQgaXMgZWFz aWVyIGZvciBtZSB0byByZWFkDQplbWFpbA0KPGJyPmZyb20gPiBzdWNoIG1haWxib3ggaGVyZSBp biBBZGVsYWlkZSkNCjxwPj5QbGVhc2UgbGV0IG1lIGtub3cNCjxicj4+QmVzdCBSZWdhcmRzDQo8 YnI+PkdpdXNlcHBlPC9ibG9ja3F1b3RlPg0KPC9odG1sPg0KDQo= --0__=Ou6T7DhQ2m4mKDGzeYRejw2B1bdvsusIxIxnOuTTiRmLq4eAc1mroHn6-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 22:43:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27905 for ; Mon, 8 May 2000 22:43:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA5D744464; Mon, 8 May 2000 16:14:35 -0400 (EDT) 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 8F75844468 for ; Mon, 8 May 2000 16:13:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:18:05 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8523444365; Mon, 8 May 2000 14:20:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 00B8344381 for ; Mon, 8 May 2000 14:20:57 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8694C52B6; Mon, 8 May 2000 14:20:56 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id BD1F652BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20452 for ; Mon, 8 May 2000 08:12:26 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:59:29 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:59:27 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA201072; Mon, 8 May 2000 21:54:20 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA46160; Mon, 8 May 2000 21:59:19 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041D8E9 ; Mon, 8 May 2000 21:59:13 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "'Anup Rao'" Cc: "'Kundan Singh'" , "'Dean Willis'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:27 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] RE: SIP & RTSP interworking? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Anup, Sorry for my poor explanation. From a global perspective, there will be one logical session. This logical session will consist of a SIP session and a RTSP session which need to be united. Given this info, your option a) would not be appropriate. option b) is what we'd like to do. >If you go with the model that the RTSP server understands SIP, then RTSP >provides a means to pass the conference ID to the RTSP server so that it can >join the SIP session and link subsequent RTSP operations to the SIP session. Wow, thanks for pointing this out. Should've noticed this before. The text is the RFC is quite clear: Separation of stream control and conference initiation: Stream control is divorced from inviting a media server to a conference. The only requirement is that the conference initiation protocol either provides or can be used to create a unique conference identifier. In particular, SIP [12] or H.323 [13] may be used to invite a server to a conference. ==== I believe my problem is solved. Thanks! Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 > -----Original Message----- > From: Anup Rao [SMTP:anrao@cisco.com] > Sent: Wednesday, March 15, 2000 4:23 PM > To: Linden deCarmo > Cc: 'Kundan Singh'; 'Dean Willis'; sip@lists.research.bell-labs.com > Subject: Re: SIP & RTSP interworking? > > > > Linden deCarmo wrote: > > > I like this a lot better, but the problem I have is this, we'd like for > BOTH > > sessions to be active at the same time and both of your proposals > require a > > teardown of the SIP session. > > > > Linden, > > I still dont understand what the application is. Your first note said : > > ************* > What I'd like to do is setup a session with SIP (via an INVITE), then > control streaming aspects via RTSP (i.e. play, pause, stop etc.). > ************* > > Implying to me that there was only one session. > > Your second note says: > > ************** > I like this a lot better, but the problem I have is this, we'd > like for BOTH > sessions to be active at the same time and both of your proposals > require a > teardown of the SIP session. > ************** > > Implying that there were two. (which I think makes sense). > > I think there are broadly two scenarios: > > a) Sending an RTSP URL to a SIP UA as part of redirection or call > termination > or transfer. The SIP session in question would be terminated. From the > SIP > point of view, it seems to make sense to put the RTSP URL in a Contact: or > Also:, exact callflows and details to be worked out. > > b) Have a RTSP controlled stream as part of a conference ie an addon to an > existing or about-to-exist SIP session. > There could be a number of interesting variants to this. > > One of them that follows the "SIP-UA knows RTSP" model: > You can have one SIP UA be the RTSP client (ie the owner/controller of the > stream if you will), and direct the stream to each SIP UA in the > session(could > be via multicast as well). Other UAs dont need to know anything about > RTSP. In > which case SIP needs a way to inform UAs that this new RTP stream will be > added > to the session which I guess it should be able to do using re-INVITEs. > If you go with the model that the RTSP server understands SIP, then RTSP > provides a means to pass the conference ID to the RTSP server so that it > can > join the SIP session and link subsequent RTSP operations to the SIP > session. > Such IDs are opaque to RTSP protocol , so the usage would depend on the > server > and application in question. > > -Anup. > > > Linden deCarmo > > Netspeak Corporation > > 902 Clint Moore Road > > Suite 104 > > Boca Raton, FL 33487 > > > > > -----Original Message----- > > > From: Kundan Singh [SMTP:kns10@cs.columbia.edu] > > > Sent: Wednesday, March 15, 2000 3:10 PM > > > To: Linden deCarmo > > > Cc: 'Dean Willis'; sip@lists.research.bell-labs.com > > > Subject: RE: SIP & RTSP interworking? > > > > > > -- > > > Kundan Singh http://www.cs.columbia.edu/~kns10 > > > > > > > This is an interesting suggestion, but the scenario I'm operating > under > > > is > > > > this: > > > > > > > > UAC<->UAC (in this case the UAC really is an RTSP server), both must > > > > understand SIP and RTSP. I need a way to tie the sessions between > two > > > > distinct protocols. Is a viable alternative to embed the RTSP SETUP > > > message > > > > as a SIP body for the INVITE? This would clearly associate the > > > sessions, > > > > but I hate to have a proprietary solution that wouldn't work with > other > > > > products that understood SIP & RTSP. > > > > > > In that case, the UA may return the RTSP Contact: URI in (say) 3xx > > > response. > > > > > > UA1 UA2 > > > INVITE > > > --------------> > > > > > > 3xx Moved > > > Contact:rtsp://server/resource > > > <------------- > > > > > > SETUP rtsp://server/resource > > > --------------> > > > . . . > > > > > > Since UA here understand both SIP and RTSP it should not be > > > a problem. > > > > > > If the SIP call is already established, and UA2 wants to > > > switch to RTSP, then (IMO) it may use blind call transfer > > > (BYE,Also:rtsp://...) to ask UA1 to connect to RTSP > > > server of UA2. Comments ?? > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 22:54:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27998 for ; Mon, 8 May 2000 22:54:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 304CC44570; Mon, 8 May 2000 17:41:17 -0400 (EDT) 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 6AF5A44566 for ; Mon, 8 May 2000 17:31:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:37:03 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5052C443BE; Mon, 8 May 2000 14:21:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 2A73A443AF for ; Mon, 8 May 2000 14:21:45 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5770152C4; Mon, 8 May 2000 14:21:44 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id B50ED52AB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18503 for ; Mon, 8 May 2000 06:09:52 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:22 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:58:18 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA153904 for ; Mon, 8 May 2000 19:53:10 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA54688 for ; Mon, 8 May 2000 19:58:09 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036C2E5 ; Mon, 8 May 2000 19:58:08 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:05 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: I-D ACTION:draft-ietf-sip-call-flows-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is the second draft of the Call Flows document (first draft was titled draft-johnston-sip-call-flows-00.txt before it was accepted as a working group draft). The major changes from the first draft are: - Converted all figures to ASCII art. - Incorporated "SIP Telephony Service Examples with Call Flows" (Sparks et al), draft-sparks-sip-service-examples-00, and also SIP Test Messages from the 2nd Bakeoff (Rosenberg and Schulzrinne) into the document. - Fixed assorted typos. - Made references to ISUP explicitly ANSI and added some comments on ITU and ETSI. - Fixed CANCEL mistakes (use of tags, end to end acknowledgments, etc.) - Added unique Authentication headers for each message. - Added Reliable Provisional Responses (PRACK) to scenario 4.1.2 for 183 Session Progress - Added simple SIP to SIP call without proxies 3.1.1 - Fixed "phone-context" and phone number handling in SIP URLs Any comments on the draft are greatly appreciated. Thanks to all the authors and the Call Flows Design Team. Alan Johnston MCI WorldCom Internet-Drafts@ietf.org wrote: > > 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 Telephony Call Flow Examples > Author(s) : A. Johnston, S. Donovan, R. Sparks,C. Cunningham, > K. Summers, D. Willis, J. Rosenberg, H. Schulzrinne, > Filename : draft-ietf-sip-call-flows-00.txt > Pages : 268 > Date : 06-Mar-00 > > This document gives examples of SIP (Session Initiation Protocol) > call flows for IP telephony and service examples. Elements in these > call flows include SIP User Agents and Clients, SIP Proxy and > Redirect Servers, and Gateways to the PSTN (Public Switch Telephone > Network). IP telephony scenarios include SIP Registration, SIP to > SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway > via SIP. Call flow diagrams and message details are shown. PSTN > telephony protocols are illustrated using ISDN (Integrated Services > Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group > B) circuit associated signaling. PSTN calls are illustrated using > global telephone numbers from the PSTN and private extensions served > on by a PBX (Private Branch Exchange). Telephony service examples > illustrated with call flows include call hold, transfer, forwarding, > screening, and Find-Me. Example SIP messages used for testing during > SIP 'bakeoff' events include SIP 'torture test' messages, and > messages with invalid parameters, methods, and tags. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-00.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-call-flows-00.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-call-flows-00.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. > > -------------------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <20000306120723.I-D@ietf.org> _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:04:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28137 for ; Mon, 8 May 2000 23:04:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A1BBC4450E; Mon, 8 May 2000 17:17:38 -0400 (EDT) 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 2165F44511 for ; Mon, 8 May 2000 17:05:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:10:44 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3C5B2443AA; Mon, 8 May 2000 14:21:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 06C13443A8 for ; Mon, 8 May 2000 14:21:31 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9CCCE52C4; Mon, 8 May 2000 14:21:29 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id BAB4452AB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18392 for ; Mon, 8 May 2000 06:05:31 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 05:59:51 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:59:49 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA90858; Mon, 8 May 2000 19:54:22 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA69180; Mon, 8 May 2000 19:59:37 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E3ED ; Mon, 8 May 2000 19:59:32 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Linden deCarmo Cc: "'Dean Willis'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:12 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] RE: SIP & RTSP interworking? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com -- Kundan Singh http://www.cs.columbia.edu/~kns10 > This is an interesting suggestion, but the scenario I'm operating under is > this: > > UAC<->UAC (in this case the UAC really is an RTSP server), both must > understand SIP and RTSP. I need a way to tie the sessions between two > distinct protocols. Is a viable alternative to embed the RTSP SETUP message > as a SIP body for the INVITE? This would clearly associate the sessions, > but I hate to have a proprietary solution that wouldn't work with other > products that understood SIP & RTSP. In that case, the UA may return the RTSP Contact: URI in (say) 3xx response. UA1 UA2 INVITE --------------> 3xx Moved Contact:rtsp://server/resource <------------- SETUP rtsp://server/resource --------------> . . . Since UA here understand both SIP and RTSP it should not be a problem. If the SIP call is already established, and UA2 wants to switch to RTSP, then (IMO) it may use blind call transfer (BYE,Also:rtsp://...) to ask UA1 to connect to RTSP server of UA2. Comments ?? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:07:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28169 for ; Mon, 8 May 2000 23:07:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA6EC4440A; Mon, 8 May 2000 15:46:24 -0400 (EDT) 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 986204440B for ; Mon, 8 May 2000 15:46:00 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:51:47 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 443794436E; Mon, 8 May 2000 14:20:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1C8BA44371 for ; Mon, 8 May 2000 14:20:17 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5326E52B6; Mon, 8 May 2000 14:20:14 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id D85C852C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20397 for ; Mon, 8 May 2000 08:10:06 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:56:56 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:56:55 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA126548; Mon, 8 May 2000 21:51:44 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA51750; Mon, 8 May 2000 21:56:43 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00419BED ; Mon, 8 May 2000 21:56:37 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "Fairlie-Cuninghame, Robert" Cc: "'sip@lists.research.bell-labs.com'" Message-ID: Date: Mon, 8 May 2000 14:10:21 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Tag Values. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com "Fairlie-Cuninghame, Robert" wrote: > > I have a couple of questions regarding the tag value added to the {To} > header. > > The SIP RFC says that the tag value should be a UUID and (from a previous > post) that the UUID should/may be constructed using the standard format. The > RFC also says that "The "tag" value MUST be globally unique and > cryptographically random with at least 32 bits of randomness." > > So I take it that the tag can either be a UUID or 32bit random number ? They are not mutually exclusive. I believe that the timestamp in the UUID is sufficiently fine grained that a UUID has 32 bits of randomness. > > It has puzzled me why many traces have "tag=xxxxxxx" where xxxxxx is a > decimal number usually much less than 2^31. Why decimal and so small ? > [Whether the field is hex or decimal or UUID shouldn't matter since a > case-insensitive string comparison of the field is used, correct?] 32 bit number is not the same thing at all as 32 bits of randomness. 32 bits of randomness means that if you look at the tags as a random process, the entropy of the probability mass function is 32 bits. A simplistic way to view this is that the tags are random numbers between 1 and 2**32, with the probability of picking any particular one being 1 in 2**32. Thus, 1 is a perfectly valid tag and just as likely to show up as 2**32 -1. > > What is the current best practice for adding a tag when there is only one > Via line present? I think the spec uses an implicit MAY for this case but > has this been upgraded/clarified to a SHOULD or MUST ? That is, a UAS > SHOULD/MUST add a tag to final responses if there is one Via header (and of > course MUST if there are multiple Via's). I think rfc2543bis will make tag addition a MUST. Having to special case this is a big pain, as it turns out. We had it as a MAY in the first place, since we wanted to keep the direct client to client case simple. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 23:11:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28213 for ; Mon, 8 May 2000 23:11:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F101E445C0; Mon, 8 May 2000 18:03:12 -0400 (EDT) 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 949194446B for ; Mon, 8 May 2000 17:59:47 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Mon, 8 May 2000 17:04:24 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQHRFZH1; Mon, 8 May 2000 18:04:17 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K365NXVB; Mon, 8 May 2000 18:04:19 -0400 Message-ID: <39173AAA.E5B25BC7@americasm01.nt.com> Date: Mon, 08 May 2000 18:07:38 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] URI's in SIP messages References: <200005081932.OAA06333@b04a45.exu.ericsson.se> Content-Type: multipart/alternative; boundary="------------880028A09547835F614D226E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------880028A09547835F614D226E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sean Olson wrote: > > The current SIP BNF allows the general form of URI (or URI-reference?) to > > be used in the request line and various headers. Observations and > > questions: > > > > 1. A valid form of URI (RFC 2396)is the empty sequence since: > > > > URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] > > > > This would permit the request line and various headers (To, From, > > Contact. ..) without an address specification which doesn't seem to make > > much sense. RFC 2396 specifies that the empty sequence URI refers to the > > start of the current document; is there any corresponding abstraction for > > SIP transcations? > > No. Please god no. Obviously RFC2396 specifies a much wider and more abstract form > of URI than is commonly used in SIP. Not everything in 2396 is appropriate for > every URI scheme. They are a set of guidelines that work more or less for the most > common URI schemes in use today: http, ftp, telnet, mailto (with some quirks), etc. > Be that as it may, they're guidelines which are now an integral part of the SIP BNF. > > The Request-URI and Contact: URIs have different requirements for parsing than the > To/From URIs. For example, a proxy can to a degree treat the To:/From: URIs > as opaque strings but MUST understand the syntax/semantics of the Request-URI. > This doesn't prevent you from doing rigorous parsing everywhere, but keep in > mind that it doesn't necessarily need to be done everywhere. Agreed, but at some point in a session the To:/From: URI's can quite possibly be put in a Request_URI for a subsequent transaction that proxies will have to worry about. > > > > > > 2. The relative URI references a resource relative to a base URI of a > > hierarchial scheme. So a similar question: is this a useful concept for > > SIP sessions? > > > > The only contexts where I would think this might be useful would be in > 1) The headers parameter of a SIP URI (for the From: and possibly To: headers) > 2) A SIP "cookie" similar to an HTTP-cookie. This hasn't really been investigated > much but would be interesting. > > In other words, I don't think it is generally useful in the usual places in a SIP > message (To/From/Contact/Request-URI). But it is potentially useful at the user interface > level or as part of some service logic. As part of a SIP message? I guess I can think of many examples where you want to map user friendly "addresses" to URI's in SIP messages, but that's out of scope for this discussion. > > > > 3. Finally RFC 2396 states (my emphasis): > > "When a URI reference is used to perform a retrieval action on the > > identified resource, the optional fragment identifier, separated from > > the URI by a crosshatch ("#") character, consists of additional > > reference information to be interpreted by the user agent after the > > retrieval action has been successfully completed. As such, it is not > > part of a URI, but is often used in conjunction with a URI." > > > > True, but this treated in very different ways by different web browsers. Some > treat it as part of the URI, others use it for "post-processing". > It's not really used in a standard way for SIP, but as stated above it really is up > to the UserAgent's interpretation. THIS IS A GOOD THING. I'm not arguing the merits of the URI syntax, just how it's used in SIP messages. > > > > > > So this very general URI seems to have a number of properties which don't > > seem to be relevant when used in place of a SIP URL. Since generality > > often has a price either in implementation or specification, i.e., lots > > of semantic constraints, does it make sense to restrict the syntactic > > form of URI used in place of a SIP URL, e.g., to the absolute-URI form? > > > > Well, if you really want to dig into this, the SIP URI as specified in 2543 is > actually a much different beast. Technically the entire SIP URL according to 2396 > falls under the "opaque_part" category of absolute URIs. What does this mean? It means > that the syntax AND semantics of a SIP URI are NOT defined in 2396 at all but left > to the definition in 2543. So from this perspective, much of 2396 does not apply to sip: > URIs. I don't know if this was the intention of the SIP authors or not. From a common > sense perspective, however, a SIP URI has all the properties of the URLs as defined > in 2396: it is a transcribable uniform resouce identifier :) > > I see no benefit in restricting the syntax of a SIP URI. If you "ignore" the fact that > the SIP URI should be treated as opaque, you can parse the SIP URI just like an > http, ftp, telnet, etc. URI. In this sense, it would actually place more of a burden > on an implementation to prescribe special syntax restrictions on a SIP URI. Furthermore, > I'd prefer to leave open the possibility for future SIP extensions which might need > something like a relative SIP URI. > Since the URI's we're discussing can end up as Request-URI's, I think the current syntax is just too general. At the very least, insisting that the scheme be present doesn't seem unreasonable. And I guess I can't quite grasp the notion of a relative URL in this context, so maybe a clarifying example would help. > > > > > Rick Workman > > Nortel Networks > > Ottawa > > -- > Sean Olson > Ericsson Inc. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------880028A09547835F614D226E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Sean Olson wrote:

> The current SIP BNF allows the general form of URI (or URI-reference?) to
> be used in the request line and various headers. Observations and
> questions:
>
> 1. A valid form of URI (RFC 2396)is the empty sequence since:
>
> URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
>
> This would permit the request line and various headers (To, From,
> Contact. ..) without an address specification which doesn't seem to make
> much sense. RFC 2396 specifies that the empty sequence URI refers to the
> start of the current document; is there any corresponding abstraction for
> SIP transcations?

No. Please god no. Obviously RFC2396 specifies a much wider and more abstract form
of URI than is commonly used in SIP. Not everything in 2396 is appropriate for
every URI scheme. They are a set of guidelines that work more or less for the most
common URI schemes in use today: http, ftp, telnet, mailto (with some quirks), etc.
 

Be that as it may, they're guidelines which are now an integral part of the SIP BNF.
 
The Request-URI and Contact: URIs have different requirements for parsing than the
To/From URIs. For example, a proxy can to a degree treat the To:/From: URIs
as opaque strings but MUST understand the syntax/semantics of the Request-URI.
This doesn't prevent you from doing rigorous parsing everywhere, but keep in
mind that it doesn't necessarily need to be done everywhere.
Agreed, but at some point in a session the To:/From: URI's can quite possibly be put in a Request_URI for a subsequent transaction that proxies will have to worry about.
 

>
> 2. The relative URI references a resource relative to a base URI of a
> hierarchial scheme. So a similar question: is this a useful concept for
> SIP sessions?
>

The only contexts where I would think this might be useful would be in
1) The headers parameter of a SIP URI (for the From: and possibly To: headers)
2) A SIP "cookie" similar to an HTTP-cookie. This hasn't really been investigated
   much but would be interesting.

In other words, I don't think it is generally useful in the usual places in a SIP
message (To/From/Contact/Request-URI). But it is potentially useful at the user interface
level or as part of some service logic.

As part of a SIP message? I guess I can think of many examples where you want to map user friendly "addresses" to URI's in SIP messages, but that's out of scope for this discussion.
 

> 3. Finally RFC 2396 states (my emphasis):
>   "When a URI reference is used to perform a retrieval action on the
>    identified resource, the optional fragment identifier, separated from
>    the URI by a crosshatch ("#") character, consists of additional
>    reference information to be interpreted by the user agent after the
>    retrieval action has been successfully completed.  As such, it is not
>    part of a URI, but is often used in conjunction with a URI."
>

True, but this treated in very different ways by different web browsers. Some
treat it as part of the URI, others use it for "post-processing".
It's not really used in a standard way for SIP, but as stated above it really is up
to the UserAgent's interpretation. THIS IS A GOOD THING.

I'm not arguing the merits of the URI syntax, just how it's used in SIP messages.
 

>
> So this very general URI seems to have a number of properties which don't
> seem to be relevant when used in place of a SIP URL. Since generality
> often has a price either in implementation or specification, i.e., lots
> of semantic constraints, does it make sense to restrict the syntactic
> form of URI used in place of a SIP URL, e.g., to the absolute-URI form?
>

Well, if you really want to dig into this, the SIP URI as specified in 2543 is
actually a much different beast. Technically the entire SIP URL according to 2396
falls under the "opaque_part" category of absolute URIs. What does this mean? It means
that the syntax AND semantics of a SIP URI are NOT defined in 2396 at all but left
to the definition in 2543. So from this perspective, much of 2396 does not apply to sip:
URIs. I don't know if this was the intention of the SIP authors or not. From a common
sense perspective, however, a SIP URI has all the properties of the URLs as defined
in 2396: it is a transcribable uniform resouce identifier :)

I see no benefit in restricting the syntax of a SIP URI. If you "ignore" the fact that
the SIP URI should be treated as opaque, you can parse the SIP URI just like an
http, ftp, telnet, etc. URI. In this sense, it would actually place more of a burden
on an implementation to prescribe special syntax restrictions on a SIP URI. Furthermore,
I'd prefer to leave open the possibility for future SIP extensions which might need
something like a relative SIP URI.
 

Since the URI's we're discussing can end up as Request-URI's, I think the current syntax is just too general. At the very least, insisting that the scheme be present doesn't seem unreasonable. And I guess I can't quite grasp the notion of a relative URL in this context, so maybe a clarifying example would help.
 
>
> Rick Workman
> Nortel Networks
> Ottawa

--
Sean Olson <sean.olson@ericsson.com>
Ericsson Inc.

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

--------------880028A09547835F614D226E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:13:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28227 for ; Mon, 8 May 2000 23:13:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E7FE44514; Mon, 8 May 2000 17:18:18 -0400 (EDT) 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 5FF1144516 for ; Mon, 8 May 2000 17:05:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:10:46 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9D797443B1; Mon, 8 May 2000 14:21:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 6F772443AF for ; Mon, 8 May 2000 14:21:35 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 81D9452B6; Mon, 8 May 2000 14:21:34 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id B2D3A52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18523 for ; Mon, 8 May 2000 06:10:38 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:17 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:58:15 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA16454; Mon, 8 May 2000 19:52:45 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA51330; Mon, 8 May 2000 19:58:01 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036BEF6 ; Mon, 8 May 2000 19:57:58 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com Cc: Robert.Sparks@wcom.com Message-ID: Date: Mon, 8 May 2000 14:10:04 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Comments on transfer draft (sparks-sip-cc-transfer-00) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com A few low-level comments: - I'm not sure "TRANSFER" is the right verb here, since transfer implies moving something from one place to another. All TRANSFER does is effectively ask the recipient to send another INVITE. It would be nice if the same action could be used (say) for mesh conferences. While I agree that using methods is better than adding headers, we don't want one method per feature, if we can help it. (I.e., we should abstract what's happening at the signaling layer and then decide what operations are needed for that rather than just map feature to request name.) Maybe PLEASE-INVITE or something along these lines. That way, if we need a 'remote BYE', we can add 'PLEASE-BYE'. - Using TRANSFER instead of INVITE with Also does have one major disadvantage, since the originator of the request will retransmit with T2 (4 seconds). - According to the rules for feature names, IETF-based extensions are single words, to avoid any possible confusion with proprietary extensions having inverted domain names. Thus, it should probably just be Requires: transfer rather than cc.transfer. (On the other hand, it's not clear this is needed at all - we don't need Require for new methods, since they already have a mechanism to say "sorry, je ne comprend pas"). - Telepathy transfer: "UA receiving a well-formed TRANSFER request SHOULD request approval from the user to proceed. In the absence of that request, or upon ^^^^^^^^ --> If there's no request, the UAS spontaneously emits an INVITE? receiving approval from the user, the UA MUST submit an INVITE to the resource identified by the Transfer-To: header using the Call-ID from the TRANSFER request." Should probably be UAS, to make things clearer. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:15:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28265 for ; Mon, 8 May 2000 23:15:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF2EB44515; Mon, 8 May 2000 17:18:25 -0400 (EDT) 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 A8A1844519 for ; Mon, 8 May 2000 17:17:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:23:56 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 795CE443BA; Mon, 8 May 2000 14:21:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 4B5AD443AF for ; Mon, 8 May 2000 14:21:42 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 80ED952BB; Mon, 8 May 2000 14:21:41 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id B967052AB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18414 for ; Mon, 8 May 2000 06:06:18 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:59:51 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:59:47 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA12248; Mon, 8 May 2000 19:54:20 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA69178; Mon, 8 May 2000 19:59:36 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E441 ; Mon, 8 May 2000 19:59:33 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Jonathan Rosenberg , John Mainwaring Cc: "Mark D. Foster" , iptel@lists.research.bell-labs.com, "'James Yu'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:12 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] URL Generalization for Portability (was TRIP) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenburg wrote: > I wonder if we can't think about this problem in more general terms. yes, please! > In the SIP model, each proxy owns some piece of the namespace > (engineering.dynamicsoft.com, for example), and is therefore responsible > for the definition of the user space (jdrosen@) within that domain. > Thats why each proxy can, an usually will, perform some kind of URI > translation independent from other proxies. Our underlying assumption > was that usernames only have meaning within their domain. For example, > with sip:jdrosen@dynamicsoft.com, only a dynamicsoft.com proxy knows how > to handle jdrosen. There might be jdrosen's in other domains that aren't > me. However, in the case of telephone numbers, the proxy that owns the > domain does not necessarily own the user space. sip:5551212@gateway.com, > for example, uses a user name that is not "owned" by gateway.com, in the > sense that this name has valid semantics outside of gateway.com. Other > domains, like wcom.com, would know how to handle this number as well. > Its possible that we might even see things besides phone numbers as user > names that are valid across multiple domains. An example is (heaven > forbid), social security numbers (in the US, at least): The underlying problem here is differentiating between a phone-number and a service-name-which-looks-like-a-number. Yes, the user=phone gives a hint on nature od address, the "+" encodding gives a hint on the scope of address, but it is still muddy. There was some discussion of this problem wrt DCS during the November interim meeting. It was suggested that a cross-domain destination which is a phone number could be better represented by a tel: URL than by confusing the scope of the user part of a sip: URL. This simplilifies life greatly. Something like INVITE premiumservice@gateway.carrier.com To: tel:5551212;trans=lnp?gdbs could be used to indicate to gateway.carrier.com that premium gateway service is requested towards the PSTN location identified by telephone number 5551212, that LNP and GDBS translation have been applied, and that the phone number is of local scope for the gateway. Incidentally, I think I just noticed a minor anomaly in the tel-url grammar -- don't see how to encode more than one future-extension field . . . -- Dean --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:19:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28305 for ; Mon, 8 May 2000 23:19:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 74E2D443EE; Mon, 8 May 2000 16:52:31 -0400 (EDT) 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 25217443E2 for ; Mon, 8 May 2000 16:51:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:57:35 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 73545443A2; Mon, 8 May 2000 14:21:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3D302443A0 for ; Mon, 8 May 2000 14:21:25 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3342C52C4; Mon, 8 May 2000 14:21:24 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 2631D52B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18318 for ; Mon, 8 May 2000 06:02:48 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:57:33 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:57:31 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA121112; Mon, 8 May 2000 19:52:22 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA49374; Mon, 8 May 2000 19:57:21 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036AFED ; Mon, 8 May 2000 19:57:19 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Anoop Tripathi Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:01 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Fault tolerance scheme for SIP Proxy servers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Anoop Tripathi wrote: > > Hi, > > Is there a draft or a generally accepted fault tolerance scheme for SIP Proxy > Servers? There is no draft. I'm not even sure there should be (at least not standards track). How a server handles fault tolerance is an implementation issue. THere are numerous capabilities of SIP you can use to build robust systems. We have discussed several on the list, including multicast, statelessness, usage of domain names instead of IP addresses, and so on. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 23:21:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28321 for ; Mon, 8 May 2000 23:21:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6EA144498; Mon, 8 May 2000 16:26:58 -0400 (EDT) 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 560D1443AC for ; Mon, 8 May 2000 16:25:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:31:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2E50644391; Mon, 8 May 2000 14:21:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 06E7444383 for ; Mon, 8 May 2000 14:21:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1995052C4; Mon, 8 May 2000 14:21:12 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 3B14A52C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id HAA19899 for ; Mon, 8 May 2000 07:58:48 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:54:39 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:54:37 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA40076; Mon, 8 May 2000 21:49:29 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA64590; Mon, 8 May 2000 21:54:28 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00416631 ; Mon, 8 May 2000 21:54:20 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "'Dean Willis'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:14 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] RE: SIP & RTSP interworking? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Dean, This is an interesting suggestion, but the scenario I'm operating under is this: UAC<->UAC (in this case the UAC really is an RTSP server), both must understand SIP and RTSP. I need a way to tie the sessions between two distinct protocols. Is a viable alternative to embed the RTSP SETUP message as a SIP body for the INVITE? This would clearly associate the sessions, but I hate to have a proprietary solution that wouldn't work with other products that understood SIP & RTSP. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 > -----Original Message----- > From: Dean Willis [SMTP:dean.willis@wcom.com] > Sent: Wednesday, March 15, 2000 2:10 PM > To: Linden deCarmo; sip@lists.research.bell-labs.com > Subject: RE: SIP & RTSP interworking? > > > Here's what I would suggest: > > Build a SIP UAS that understands the RTSP end and contains stream > management > logic. This UAS either reinvites to establish the link to RTSP streams, or > copies the RTP from each stream back into the media path for the remote > UA. > > I know of some people(s) who are already using each approach to build a > voice mail system that can use a standard RTSP server as a media store. > Makes unified messaging with URL passing MUCH easier. > > -- > dean > > > -----Original Message----- > > From: owner-sip@lists.research.bell-labs.com > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Linden > > deCarmo > > Sent: Tuesday, March 14, 2000 7:27 AM > > To: 'sip@lists.research.bell-labs.com' > > Subject: SIP & RTSP interworking? > > > > > > What would be the proper (or suggested) procedure to tie a SIP > > session to an > > RTSP session? > > > > What I'd like to do is setup a session with SIP (via an INVITE), then > > control streaming aspects via RTSP (i.e. play, pause, stop etc.). > > However, > > its not clear to me how I tie the RTSP session id to the previously > > established SIP session. > > > > Thanks. > > > > Linden deCarmo > > Netspeak Corporation > > 902 Clint Moore Road > > Suite 104 > > Boca Raton, FL 33487 > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:23:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28355 for ; Mon, 8 May 2000 23:23:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0242444E5; Mon, 8 May 2000 16:52:02 -0400 (EDT) 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 111F8443EE for ; Mon, 8 May 2000 16:51:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 16:57:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 4A493443A6; Mon, 8 May 2000 14:21:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0836C443A4 for ; Mon, 8 May 2000 14:21:28 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DFBAD52B6; Mon, 8 May 2000 14:21:26 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 9EED952BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18404 for ; Mon, 8 May 2000 06:06:05 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:59:58 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:59:57 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA95222; Mon, 8 May 2000 19:54:23 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA69182; Mon, 8 May 2000 19:59:38 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036E3A2 ; Mon, 8 May 2000 19:59:32 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Jeff.Mark@dialogic.com Cc: sip@lists.research.bell-labs.com, Kalon.Kelley@dialogic.com Message-ID: Date: Mon, 8 May 2000 14:10:12 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: I-D ACTION:draft-mark-sip-dmcs-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Also, please note that an IPR statement has been made regarding this draft. It can be found at: http://www.ietf.org/ietf/IPR/DIALOGIC-SIP-DMCS -Jonathan R. Jeff.Mark@Dialogic.com wrote: > > Hi all, > > Just wanted to let you know of a new draft. Below is the announcement in > case you missed it. We know there is other work going on in the call > control services area (draft-ietf-sip-cc-01, and new drafts > draft-campbell-sip-cc-framework-00 and draft-sparks-sip-cc-transfer-00) > and hope the ideas presented in our draft below are of interest to others. > > Comments are appreciated. > > Thanks! > > -Jeff > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 23:26:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28371 for ; Mon, 8 May 2000 23:26:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10AD7443EF; Mon, 8 May 2000 17:17:19 -0400 (EDT) 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 6022F4450E for ; Mon, 8 May 2000 17:05:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:10:45 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1371C443AD; Mon, 8 May 2000 14:21:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id D9D8B443A8 for ; Mon, 8 May 2000 14:21:32 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D1B8952AB; Mon, 8 May 2000 14:21:31 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id A6CCD52BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18563 for ; Mon, 8 May 2000 06:11:39 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:47 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:58:42 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA127602; Mon, 8 May 2000 19:53:34 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA31746; Mon, 8 May 2000 19:58:33 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036CBB0 ; Mon, 8 May 2000 19:58:30 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "Liess, Laura" Cc: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:07 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: uploading services from the user's home network to a sip server of the visited network within a 3G.IP environement Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com "Liess, Laura" wrote: > > Hi, > > after doing a very good job by deciding to take SIP for call control for multimedia services within 3G.IP >networks, the 3G.IP operators have a lot of open items concerning the architecture, one of them being which >network controls the services for a roaming user: the home network, the visited network or shared control. >The concrete question: how can I upload at the begin or during the call the roamimg user's services >available in the home network into the SIP proxy of the visited network? As far as I know, the CPL and >REGISTER helps me to upload services only from the UA to the proxy. I'm not an expert in wireless, so I'm not certain of the scope of the services we are talking about. Mid call services, for example, are not currently within the scope of CPL. However, there is nothing which prevents the CPL-upload-in-register mechanism from being used by a server to upload scripts to another server. Registrations, in general, can be used for third party controls. The From field identifies the party initiating the registration. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:29:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28382 for ; Mon, 8 May 2000 23:29:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 976DD4443F; Mon, 8 May 2000 16:03:01 -0400 (EDT) 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 34918443C9 for ; Mon, 8 May 2000 15:59:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:04:55 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C67C44437B; Mon, 8 May 2000 14:20:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 240E04436A for ; Mon, 8 May 2000 14:20:19 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E231052BB; Mon, 8 May 2000 14:20:18 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id A26F552D4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20316 for ; Mon, 8 May 2000 08:07:34 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 08:01:10 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 08:01:07 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA208940; Mon, 8 May 2000 21:56:00 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id WAA36274; Mon, 8 May 2000 22:00:59 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0042012E ; Mon, 8 May 2000 22:00:56 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: James Yu Cc: John Mainwaring , Mark Foster , iptel@lists.research.bell-labs.com, sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:31 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: TRIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com James Yu wrote: > > For overlap signaling, a GW or LS that receives a call with partial address > information may not know that the address info. is complete. If it launches > a query (DNS or NPDB), the entity that has the "number portability" info. > won't be able to find the info. because the address info. is incomplete. It > seems that either this LS or GW may wait a little while to see whether there > are subsequent address info. before launching the query, or it can launch a > query (DNS or NPDB-like), receives an error (hope that it is specific such > as incomplete address instead of something ambiguous), and then wait for > additional address info. before timing out. I think Dean had sent out some pseudo-code some time back on how trip and enum and overlap interact, and this was more or less what the code suggested. I believe he thought it was a bad thing, and so do I. Overlap dialing seems fundamentally in conflict with LNP or enum queries at the local outbound proxy. To do LNP, the local outbound proxy needs to have the entire string of digits before it can perform the query. But, overlap seems to imply that it won't ever know the entire string of digits, as it doesn't have knowledge of those numbering plans. It just forwards the request to some other proxy or gateway that does. Sooo, it would seem that a proxy should only use enum or LNP for numbers it knows to be complete. This means that for overlap dialing, the LNP query will happen close to the destination (possibly even in the PSTN), not unlike the N-1 case we've been discussing. However, for en-bloc, it can happen anywhere. This does seem to imply that a proxy needs to know whether the number in the request URI of an incoming request is en-bloc or overlap. It could make this determination if it knew the structure of the numbering plans, but thats unlikely. Might we need a parameter somewhere (ugh)? I really hate to crowd SIP with things to support old legacy technologies like overlap, so if we can avoid this, I'd be very happy. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:32:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28816 for ; Mon, 8 May 2000 23:32:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7F5F44473; Mon, 8 May 2000 16:14:04 -0400 (EDT) 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 5B90D443C3 for ; Mon, 8 May 2000 16:13:55 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 16:18:07 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C20C64438A; Mon, 8 May 2000 14:21:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7E04544383 for ; Mon, 8 May 2000 14:21:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B803452AB; Mon, 8 May 2000 14:21:04 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id D6E7152C4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20428 for ; Mon, 8 May 2000 08:11:10 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:57:13 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:57:10 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA162162; Mon, 8 May 2000 21:50:42 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA71492; Mon, 8 May 2000 21:55:41 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00418573 ; Mon, 8 May 2000 21:55:40 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com Cc: byerly@cisco.com, dwilli@cisco.com Message-ID: Date: Mon, 8 May 2000 14:10:16 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] New I-D: SIP Security using CHAP-Password Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi guys, Attached is an initial I-D on SIP Security using CHAP-Password. This I-D allows authentication of SIP clients using a backend Radius (RFC 2138) server. I'd appreciate comments/criticisms/suggestions and I'd like to trigger a discussion on the outstanding issues. Enjoy! Bryan Bryan J. Byerly byerly@cisco.com (919) 392-7091 Internet Engineering Task Force Bryan J. Byerly Internet Draft David Williams draft-byerly-sip-radius-00.txt Cisco Systems March, 2000 Expires: September, 2000 SIP Security using CHAP-Password Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a proposed extension to SIP. This document proposes using an alternative SIP security mechanism for use in Proxy-Authorization or Authorization headers in order to support SIP client Authentication using backend RADIUS servers. The introduction of this extension would allow a SIP proxy (or called SIP client) to authenticate a SIP client using a backend RADIUS server. Byerly/Williams draft-byerly-sip-radius-00.txt Page 1 Internet Draft SIP Security using CHAP-Password March 2000 1 Introduction Some ISPs currently use RADIUS servers to authenticate (and implicitly authorize) dialup users for PPP service. It would be advantageous to allow the re-use of this same RADIUS infrastructure for SIP client authentication. Although the currently defined mechanisms for SIP client authentication [section 3.2.2.2 of RFC 2617] and RADIUS authentication using a User-Password or CHAP-Password [sections 5.2, 5.3 of RFC 2138] both use MD5, they run MD5 across differently formatted messages. There are two approaches to solving this problem. One is to extend RADIUS to support HTTP-Digest; the other is to extend the SIP list of authentication schemes to support a CHAP-Password. This document proposes extending the SIP list of authentication schemes to support a CHAP-Password. 2 Definitions The definitions of several terms used in this document follow: nonce A nonce is a octet string that is uniquely generated each time a request is made. It is recommended that a nonce be constructed to exhibit global and temporal uniqueness. The SIP specification [SIP] calls this a "nonce-value" (Section 3.2.1 of [DIG]). The RADIUS specification calls this a (random) challenge. (Section 2.2 of [RAD]) In RADIUS, the nonce can be placed in the Request Authenticator (Section 4.2 of [RADIUS]) or in the CHAP-Challenge attribute. (Section 5.40 of [RADIUS]) The CHAP Response in the CHAP-Password and the nonce-value in the HTTP-Digest use a 16-octet nonce. sequence number A sequence number is a monotonically increasing integer. Sequence numbers allow detection of replays. The "nonce-count" of the HTTP-Digest is a 32-bit sequence number (formatted as 8 hex digit characters) The "Chap-ID" in the CHAP-Password is a 1 octet sequence number. Byerly/Williams draft-byerly-sip-radius-00.txt Page 2 Internet Draft SIP Security using CHAP-Password March 2000 shared secret A secret shared between two entities. In this document, we assume that: - A user shares a secret (i.e. password) with the RADIUS server. - The PPP NAS (or SIP proxy) also shares a secret with the RADIUS server. 3 Analogous Model - PPP When a SIP proxy is used for user authentication an analogy can be drawn from PPP message flows. 3.1 Message flow for PPP user authentication with Radius backend: dialup PPP RADIUS user NAS server | | | |--modem connection--->| | | | | | PPP | | |<-Configure-Request---| | | | | | PPP | | |--Configure-Ack------>| | | | | | |--Access-Request------>| | | | | |<-Access-Challenge-----| | | | |<-CHAP Challenge------| | | | | |--CHAP Response------>| | | | | | |--Access-Request------>| | | | | |<-Access-Accept--------| | | | | | | Byerly/Williams draft-byerly-sip-radius-00.txt Page 3 Internet Draft SIP Security using CHAP-Password March 2000 3.2 Message flow for SIP user authentication with Radius backend: SIP SIP RADIUS client proxy server | | | |--[1] INVITE--------->| | | | | | |--[2] Access-Request-->| | | | | |<-[3] Access-Challenge-| | | | |<-[4] 407-------------| | | (Proxy-Authenticate:) | | | | |--[5] INVITE--------->| | |(Proxy-Authorization:) | | | | | |--[6] Access-Request-->| | | | | |<-[7] Access-Accept----| | | | | |--[8] INVITE------------------> | | | . . . |<--200---------------|<--200------------------------ When a PPP client authentication failure occurs, in some cases the PPP NAS implementation terminates the link. However, other PPP NAS implementations may choose to allow the client to continue, but with a filtered list of services. A PPP NAS may allow traffic which lets the user update his credentials (such as email to the sysadmin). Similarly, a SIP proxy server may wish to allow the user to place calls to the ISP's home office (to obtain updated credentials). A SIP proxy server may also wish to allow 911 calls to complete. 4 Current PAP/CHAP/SIP/HTTP Authentication mechanisms The following sections briefly describe the current mechanisms used for user authentication in PPP (PAP/CHAP) and HTTP/SIP (Basic and Digest). Byerly/Williams draft-byerly-sip-radius-00.txt Page 4 Internet Draft SIP Security using CHAP-Password March 2000 4.1 PAP authentication mechanism Why not use RADIUS User-Password? The RADIUS User-Password attribute is calculated as: User-Password = md5hash(NAS-secret, nonce) XOR user-password If a PPP user sends his password in cleartext (eg. using PAP), then the PPP server can calculate the User-Password attribute of the Access-Request to authenticate the user. It is undesirable for a SIP user to send his password in cleartext. If the user does NOT send his password in cleartext, the User-Password cannot be calculated by either the PPP client (because he doesn't know the NAS-secret) or the NAS (because he doesn't know the user-password). 4.2 CHAP authentication mechanism PPP defines usage of the CHAP-Password (as an alternative to User-Password) to avoid cleartext transmission of the users's password. When a CHAP-Password is used a cleartext sequence number, cleartext nonce, and the following MD5 hash are transmitted by the client: md5hash(seqnum, user-password, nonce) The nonce can be generated by the client or the server. If the nonce is generated by the client, the server may choose to accept it or may challenge the client with a new nonce. 4.3 SIP/HTTP authentication mechanisms: SIP and HTTP define two basic authentication mechanisms. HTTP-Basic and HTTP-Digest. Usage of HTTP-Basic involves sending the the user's password in cleartext, and is thus undesirable. The currently defined mechanisms for SIP client authentication using HTTP-Digest are taken from section 3.2.2.2 of RFC 2617 and the hash constructions are repeated here for clarity: If the directive's value is "MD5" or is unspecified, then A1 is: A1 = unq(username-value) ":" unq(realm-value) ":" passwd If the directive's value is "MD5-sess", then A1 is Byerly/Williams draft-byerly-sip-radius-00.txt Page 5 Internet Draft SIP Security using CHAP-Password March 2000 calculated only once - on the first request by the client following receipt of a WWW-Authenticate challenge from the server. It uses the server nonce from the challenge, and the first client nonce value to construct A1 as follows: A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ":" unq(nonce-value) ":" unq(cnonce-value)) This creates a 'session key' for the authentication of subsequent requests and responses which is different for each "authentication session", thus limiting the amount of material hashed with any one key. [RFC 2617] 5 Interaction/Mapping problems There are two problems: 5.1 CHAP-Password construction problem: If a SIP proxy receives an HTTP-Digest from a SIP client (without CHAP-Password support), the SIP proxy is unable to construct a CHAP-Password. This is because the SIP proxy doesn't have access to the client's password. The SIP proxy only has access to a hash of the client's password, and (as dicussed above) this hash is computed across a message whose format is different than the RADIUS server expects. Nor can the SIP proxy simply forward the hash calculated in the HTTP-Digest: 5.2 Message mapping problem: Since the message format over which a hash is computed is different for the CHAP-Password than the message format used for the HTTP-Digest "MD5" or "MD5-sess" algorithms, a RADIUS server could not verify a proxied HTTP-Digest (which uses either the "MD5" or "MD5-sess" algorithms). The RADIUS server would discard such a HTTP-Digest formulated hash as invalid. Here is the proposed solution to these problems: 6 SIP Security using CHAP-Password To solve these problems, we specify an additional mechanism for SIP security which uses a CHAP-Password. CHAP-Password can either be used for endpoint-to-endpoint authentication (when used in WWW-Authenticate and Authorization) or for endpoint-to-proxy authentication (when used in Proxy-Authenticate and Proxy-Authorization). Byerly/Williams draft-byerly-sip-radius-00.txt Page 6 Internet Draft SIP Security using CHAP-Password March 2000 6.1 The WWW-Authenticate Response Header When a CHAP-Password is used for SIP security, the WWW-Authenticate Response Header (3.2.2 of RFC 2617) is defined as: WWW-Authenticate = "WWW-Authenticate" ":" "CHAP-Password" chap-challenge chap-challenge = * (";" chap-params ) chap-params = chap-username | chap-algorithm | chap-id | nonce chap-algorithm = "algorithm" "=" ( "MD5" | token ) chap-username = quoted-string chap-id = "id" "=" + ( digit ) chap-nonce = "nonce" "=" nonce-value chap-nonce-value = <"> 32LHEX <"> LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" chap-algorithm: A string indicating the authentication method to be used. chap-username: A string containing the user name. chap-id: The CHAP Identifier is a one octet sequence number. nonce: A string of 32 hex digits. The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. Example: WWW-Authenticate: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="10131973aaa511bb05261975aaa505fb" The chap-username is copied from the User-Name attribute of the Access-Challenge message received from the RADIUS server. The chap-id is copied from the (1-octet) Identifier field of the Access-Challenge message received from the RADIUS server. The chap-nonce-value is copied from the Access-Challenge message from the RADIUS server (from the CHAP-Challenge attribute if present, otherwise from the Request Authenticator). Byerly/Williams draft-byerly-sip-radius-00.txt Page 7 Internet Draft SIP Security using CHAP-Password March 2000 6.2 The Authorization Request Header When challenged, the SIP client is expected to retry the request, passing an Authorization header line, which is defined as follows: Authorization = "Authorization" ":" "CHAP-Password" chap-response-line chap-response-line = * (";" chap-response-params ) chap-response-params = chap-username | chap-id | nonce | chap-response chap-response = "response" "=" chap-response-value chap-response-value = <"> 32LHEX <"> chap-response-value: A string of 32 hex digits computed as defined in Section 4.1 of RFC1994, which proves that the user knows a password. Example: Authorization: CHAP-Password ;username="byerly" ;id=0 ;nonce="10131973aaa511bb05261975aaa505fb" ;response="f53a66e43c12a383aa65219ec873ce35" The client MUST increment the CSeq header before resubmitting the request. A server MAY be configured not to generate nonces only if replay attacks are not a concern. The Response Value (chap-response-value) of the CHAP-Password is computed per Section 4.1 of RFC 1994 [CHAP]. The 16-octet Response Value of the CHAP-Password should be formatted as 32 hex digits and placed in the "chap-response-value" of the Authorization request. The chap-id should be placed in the (1-octet) Identifier field of the Access-Request message to the RADIUS server. The chap-id should also be placed in the (1-octet) CHAP Identifier field of the CHAP-Password attribute of the Access-Request message to the RADIUS server. (See sections 3, 5.3, [RAD]) The nonce-value SHOULD be placed in the Request Authenticator of the Access-Request message to the RADIUS server. (See section 3, [RAD]) Alternatively, the nonce-value MAY be placed in a CHAP-Challenge attribute in the Access-Request message to the RADIUS server. (See section 5.3, [RAD]) The chap-response-value should be placed in the 16-octet String field of the CHAP-Password attribute in the Access-Request message to the RADIUS server. (See section 5.3, [RAD]) Byerly/Williams draft-byerly-sip-radius-00.txt Page 8 Internet Draft SIP Security using CHAP-Password March 2000 7 Proxy-Authenticate and Proxy-Authorization The CHAP-Password authentication scheme may also be used for authenticating users to proxies. 8 Security Considerations Security issues are the primary topic of this RFC. The security issues for this document are the same as those in the Security Considerations sections of RFC 1994 [CHAP] and RFC 2617 [DIG]. 9 Further Examples Only the relevant headers have been included in the following examples. 9.1 User Authentication using backend RADIUS server - With Server Challenge. [1] SIP Client to SIP proxy server: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345600@cisco.com CSeq: 1 INVITE Proxy-Authorization: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" ;response="bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" Content-Type: application/sdp NOTE: The Proxy-Authorization header sent in the first message may have been cached from a previous exchange with the SIP proxy. If the SIP client does not place a Proxy-Authorization header in the INVITE, the RADIUS server will (transitting through SIP proxy) challenge him with a new nonce. [2] SIP proxy server to RADIUS server: Code = 1 (Access-Request) ID = 0 Length = 71 Request Authenticator = {16 octet random number also used as CHAP challenge (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)} Byerly/Williams draft-byerly-sip-radius-00.txt Page 9 Internet Draft SIP Security using CHAP-Password March 2000 Attributes: User-Name = "byerly" CHAP-Password = {1 octet CHAP ID (00) followed by 16 octet CHAP response (bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb)} NAS-IP-Address = 192.168.1.16 NAS-Port = 5 [3] RADIUS server to SIP proxy server: Code = 11 (Access-Challenge} ID = 0 (same as in Access-Request) Length = 68 Attributes: Reply-Message = "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" State = {Magic Cookie to be returned along with user's response; in this example 8 octets of data} [4] SIP proxy server to client: SIP/2.0 407 Proxy Authentication required From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345600@cisco.com CSeq: 1 INVITE Proxy-Authenticate: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="cccccccccccccccccccccccccccccccc" State: {Magic Cookie from Access-Challenge packet, unchanged} (formatted as hex digits) NOTE: In this instance, the RADIUS server chooses to re-challenge the SIP client with a new nonce. [5] SIP Client to SIP proxy server: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345600@cisco.com CSeq: 2 INVITE Content-Type: application/sdp Proxy-Authorization: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="cccccccccccccccccccccccccccccccc" ;response="dddddddddddddddddddddddddddddddd" State: {Magic Cookie from Access-Challenge packet, unchanged} (formatted as hex digits) Byerly/Williams draft-byerly-sip-radius-00.txt Page 10 Internet Draft SIP Security using CHAP-Password March 2000 [6] SIP proxy server to RADIUS server: Code = 1 (Access-Request) ID = 1 (Note that this changes) Length = 71 Request Authenticator = {NEW 16 octet CHAP challenge ()} Attributes: User-Name = "byerly" CHAP-Password = {1 octet CHAP ID followed by 16 octet CHAP response (dddddddddddddddddddddddddddddddd)} NAS-IP-Address = 192.168.1.16 NAS-Port = 5 State = {Magic Cookie from Access-Challenge packet, unchanged} [7] RADIUS server to SIP proxy server: Code = 2 (Access-Accept) ID = 1 (same as in Access-Request) Length = 30 [8] SIP proxy server to next hop UAS: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345600@cisco.com CSeq: 2 INVITE Content-Type: application/sdp 9.2 User Authentication using backend RADIUS server - Without Server Challenge. [a] SIP Client to SIP proxy server: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345601@cisco.com CSeq: 3 INVITE Proxy-Authorization: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee" ;response="ffffffffffffffffffffffffffffffff" Content-Type: application/sdp Byerly/Williams draft-byerly-sip-radius-00.txt Page 11 Internet Draft SIP Security using CHAP-Password March 2000 [b] SIP proxy server to RADIUS server: Code = 1 (Access-Request) ID = 0 Length = 71 Request Authenticator = {16 octet random number also used as CHAP challenge (eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)} Attributes: User-Name = "byerly" CHAP-Password = {1 octet CHAP ID (00) followed by 16 octet CHAP response (ffffffffffffffffffffffffffffffff)} NAS-IP-Address = 192.168.1.16 NAS-Port = 5 [c] RADIUS server to SIP proxy server: Code = 2 (Access-Accept) ID = 1 (same as in Access-Request) Length = 56 [d] SIP proxy server to next hop UAS: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345601@cisco.com CSeq: 3 INVITE Content-Type: application/sdp There are two cases when a SIP client could pre-send a Proxy-Authorization that the RADIUS server might accept: 1) The RADIUS server originally generated the nonce when challenging the SIP client on a previous call. The SIP client is reusing the previously sucessful Authorization for a new call. 2) The SIP client originally generated the nonce. The parsed format of the nonce is known to both the SIP client and the RADIUS server. The nonce contains a timestamp which the RADIUS server can extract and use to limit the replay window. Since a RADIUS server silently discards invalid/unauthorized requests, this scheme is not subject to the form of the man-in-the-middle attack where Mallory sends a bogus request to the server and uses the response to make the client believe she is a legitimate server. To dos: 1) Fix the RADIUS Lengths to be correct 2) Calculate real MD5 hashes Byerly/Williams draft-byerly-sip-radius-00.txt Page 12 Internet Draft SIP Security using CHAP-Password March 2000 Outstanding issues: 1) Do we/how do we support the RADIUS State: attribute? What are the implications for collision with (DCS-)State: object? 2) Do we reuse the RADIUS NAS-Port and NAS-Port-Type attributes to allow the RADIUS server to have media port control over calls? (eg. using UDP port numbers for RTP streams) 10 Acknowledgements We would like to thank Roger Levesque, David Oran, Mike Thomas, David Daiker, Shail Bhatnagar, and Denise Caballero-McCann for discussions on the need for and improvements to this draft. We would also like to thank Tyrone Floryanzia for his insights on H.323 gateway/gatekeeper call authorization using RADIUS. 11 References [SIP] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP: Session Initiation Protocol", RFC 2543, March 1999. [RAD] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote Authentication Dial in User Service (RADIUS)," RFC 2138, April 1997. [DIG] Franks, J, et al. "HTTP Authentication: Basic and Digest Access Authentication," RFC 2617, June 1999. [CHAP] Simpson, W. "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [PAP] Lloyd, B, W. Simpson. "PPP Authentication Protocols", RFC 1334, October 1992. [PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DayDreamer, July 1994. [MD5] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", MIT Laboratory for Computer Science and RSA Data Security, Inc., RFC 1321, April 1992. [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC-2119, March 1997. Byerly/Williams draft-byerly-sip-radius-00.txt Page 13 Internet Draft SIP Security using CHAP-Password March 2000 Authors' Addresses Bryan J. Byerly Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA Email: byerly@cisco.com David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA Email: dwilli@cisco.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 May 8 23:39:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28848 for ; Mon, 8 May 2000 23:39:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D9E9944535; Mon, 8 May 2000 17:18:01 -0400 (EDT) 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 D22E444514 for ; Mon, 8 May 2000 17:05:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:10:46 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0E3B5443A8; Mon, 8 May 2000 14:21:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id D07FF443AF for ; Mon, 8 May 2000 14:21:33 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1910F52AB; Mon, 8 May 2000 14:21:33 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 0262452C4 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18360 for ; Mon, 8 May 2000 06:04:04 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:00 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:57:58 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA67200 for ; Mon, 8 May 2000 19:52:32 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA42136 for ; Mon, 8 May 2000 19:57:49 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036BA27 ; Mon, 8 May 2000 19:57:45 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:03 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] new internet drafts posted Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I've just posted an Internet Draft on the compromise position reached regarding the DCS group's two-stage invite proposal. It's entitled "Integration of Resource Management and SIP for IP Telephony", and is filed as draft-manyfolks-sip-resource-00. Until it appears in the archives, it may be obtained via anonymous ftp ftp://ftp.research.att.com/dist/wtm/draft-manyfolks-sip-resource-00.txt This draft is a combination of two previous drafts, draft-ietf-mmusic-sdp-qos-00, and draft-dcsgroup-sip-resource-00, and discusses how network QoS and security establishment can be made a precondition to sessions initiated by SIP, and how the resulting call setup mechanism achieves many goals, including those of the PacketCable DCS project. We anticipate no problems in reissuing this draft shortly after Adelaide with "full conformance with Section 10 of RFC2026." Also just posted are updates to 5 of the DCS group's Internet Drafts, draft-dcsgroup-sip-arch-01 draft-dcsgroup-sip-call-auth-01 draft-dcsgroup-sip-state-01 draft-dcsgroup-sip-privacy-01 draft-dcsgroup-sip-proxy-proxy-01 These drafts reflect the discussion at the November working group meeting, and further work since. Until they appear in the archives, they may be obtained via anonymous ftp ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-arch-01.txt ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-call-auth-01.txt ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-state-01.txt ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-privacy-01.txt ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-proxy-proxy-01.txt 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 Mon May 8 23:43:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28886 for ; Mon, 8 May 2000 23:43:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7B6F44598; Mon, 8 May 2000 17:46:11 -0400 (EDT) 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 A8BED4459A for ; Mon, 8 May 2000 17:45:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:50:15 EDT 2000 Received: by lists.bell-labs.com (Postfix) id DE65844347; Mon, 8 May 2000 15:07:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id AF00544341 for ; Mon, 8 May 2000 15:07:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 581C452B6; Mon, 8 May 2000 15:07:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6EED252AB for ; Mon, 8 May 2000 15:07:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 15:07:01 EDT 2000 Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Mon May 8 15:07:00 EDT 2000 Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 15:06:42 -0400 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A609823E@crash.engineering.netspeak.com> From: "Neville O'reilly" To: "'S_S_Dinesh/India/IBM@au1.ibm.com'" , Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: RE: [SIP] Re: "headers" in SIP-URL Date: Mon, 8 May 2000 15:06:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I believe that's true i.e. most of the extensions (maddr,headers, etc) are not allowed in the To, From parameters, but can be used in the Contact parameters -----Original Message----- From: S_S_Dinesh/India/IBM@au1.ibm.com [mailto:S_S_Dinesh/India/IBM@au1.ibm.com] Sent: Monday, May 08, 2000 4:40 AM To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: [SIP] Re: "headers" in SIP-URL Shail Bhatnagar wrote: > > A look at the syntax of SIP-URL shows that headers can be defined in a SIP-URL > itself. However, the spec also says they MUST NOT be present in From/To and > Request-URI. Does it mean they can be present in Contact header (the addr-spec > portion of Contact) ?? > I don't see any good reason for headers being allowed inside a SIP-URL and I > would be curious to know how many implementations actually introduce it in > SIP-URL ( probably the Contact header) and rely on it. In a redirect, you can play tricks such as adding new headers to the next, redirected call. (For example, the redirect server could provide the password for another call.) While I doubt that it is used right now, it seems like a feature worth having around. > > Thanks, > > -- > Best regards, > Shail -- 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 Mon May 8 23:47:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28963 for ; Mon, 8 May 2000 23:47:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E204A44496; Mon, 8 May 2000 16:40:45 -0400 (EDT) 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 C5E1A44497 for ; Mon, 8 May 2000 16:39:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:44:24 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 26F5544383; Mon, 8 May 2000 14:21:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BD6ED44396 for ; Mon, 8 May 2000 14:21:14 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id F401552BB; Mon, 8 May 2000 14:21:14 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 7CE0F52B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id HAA19887 for ; Mon, 8 May 2000 07:58:14 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 07:55:30 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:55:29 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA84428; Mon, 8 May 2000 21:50:03 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA53140; Mon, 8 May 2000 21:55:20 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.004179B3 ; Mon, 8 May 2000 21:55:09 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "yinshaohua" Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:18 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: About "The SIP servlet API" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, The "SIP Servelet API" and "Building a SIP Stack" are two very different things. If you want to build a SIP Stack, which can be used in many softwares as you say, you are looking at a generic stack that can be used to build UAs, Proxies, Redirects etc. In which case, you should not be bulding a SIP Servelet API only - this document models itself to the usual Web Server- Sevelet interface and focusses prmarily on Java, and for a specific intention - deferring SIP controls to Java classes as 'SIP Servelets' Again, thats harldy building a stack to suit all applications. Of course, you could derive APIs from it if you so wish, but the bottom line is what you want to do (build a generic sip stack) and what the servelet API propses are two different things. If your friend wants a servelet interface, and you think the servelet API draft suits you, sure you could implement it, but again, it does not *replace* a generic SIP stack, it would add on to it. Why dont you look at http://www.cs.columbia.edu/~hgs/sip/implementations.html - there are companies that have implemented generic stacks, and some of their links (follow it from the implementations page) give you an idea of expected features from a generic SIP Stack Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "yinshaohua" on 03/14/2000 01:02:09 PM Please respond to "yinshaohua" To: sip@lists.research.bell-labs.com cc: Subject: About "The SIP servlet API" Hi : Now I have a discussion with my fellow, would you give some suggestions ? We want to make a SIP Stack which can be used in many softwares. My fellow consider that the SIP Stack will be realized providing that it presents the API of the draft " The SIP Servlet API". But I have some questions about the API: A. When using in sip server,the servlet dispaly less role: decode the SIP message and the decoded header can be reached by server , store the trasaction (call-id, to etc), create message and may set some values according to the transaction,retransmissions. In section 5.3 of the draft, there writes " These headers (call-id, from,to,cseq) should not need to be manipulated directly by servlets ", I think A SIP stack SHOULD complete essential sip call management and process some parameters, sending only the useful infomation for service but not all parameters of message to other module. B. As a module of a software, the provided API is so many that it can be said the module is not encapsulated. So it not benefit to software maintenance. I think a SIP stack only gives a series of abstract API which can be used by other module to complete the service stipulated by the protocol C. Due to so many API, it is difficult to replant a servlet to other use, meanwhile, the servlet is diffcult to maintain because it have not a legible limit with other module. D. The SIP STACK should guarantee the SIP message sent by it accord with SIP protocol, but the servlet will not due to offering the API.So there may send unlawful message when the servlet use in other software. Please give some suggestions. Thanks! Shaohua Yin 2000/3/10 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:50:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28980 for ; Mon, 8 May 2000 23:50:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D668445B1; Mon, 8 May 2000 17:58:02 -0400 (EDT) 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 9B4FC444C4 for ; Mon, 8 May 2000 17:57:55 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 18:03:24 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6AE964434D; Mon, 8 May 2000 17:37:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 436F344341 for ; Mon, 8 May 2000 17:37:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C0F7A52C4; Mon, 8 May 2000 17:37:06 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 0EA3352B6 for ; Mon, 8 May 2000 17:37:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 17:35:34 EDT 2000 Received: from ids2.idsonline.com ([205.177.236.32]) by dusty; Mon May 8 17:35:33 EDT 2000 Received: from 21rst-century.com (laurel-md-227.idsonline.com [209.8.42.227]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id RAA02035; Mon, 8 May 2000 17:46:15 -0400 Message-ID: <39173312.C6E928E1@21rst-century.com> Date: Mon, 08 May 2000 17:35:14 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: S_S_Dinesh/India/IBM@au1.ibm.com Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] New I-D available soon References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit S_S_Dinesh/India/IBM@au1.ibm.com wrote: > Folks, > > I've just posted an individual Internet Draft which may be of interest. > Its entitled "Guidelines for Authors of SIP Extensions". Its discusses > issues that writers of SIP extensions should consider while developing > them and writing them up. It also gives some guidance on what things > make good SIP extensions, and what things do not. Until it appears in > the archives, you can pick up a copy at: > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-guidelines-00.txt > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip CAN'T THESE BE SHUT OFF ? They all seem to be old, and E-mail to the source bounces. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@21rst-century.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 May 8 23:52:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28996 for ; Mon, 8 May 2000 23:52:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 478E7443B2; Mon, 8 May 2000 16:14:18 -0400 (EDT) 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 5D14A44464 for ; Mon, 8 May 2000 16:13:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:18:05 EDT 2000 Received: by lists.bell-labs.com (Postfix) id EC11444381; Mon, 8 May 2000 14:20:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9468644383 for ; Mon, 8 May 2000 14:20:58 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E49CA52AB; Mon, 8 May 2000 14:20:57 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 2CED752C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20297 for ; Mon, 8 May 2000 08:07:07 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:56:44 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:56:41 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA212178; Mon, 8 May 2000 21:51:34 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA51390; Mon, 8 May 2000 21:56:32 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041980A ; Mon, 8 May 2000 21:56:27 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: John Mainwaring Cc: "Mark D. Foster" , iptel@lists.research.bell-labs.com, "'James Yu'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:20 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: TRIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > John Mainwaring wrote: > > |The problem is related to past discussions on the SIP mailing list > |regarding overlap dialing. A terminating gateway would look at > |sip:1212344, and know how to route it, but might not know whether > this > |was a dialed number with more digits coming, or an LRN. Does it > matter? > |Not being an ISUP expert, I'm not sure. If it does matter, something > |like user=lrn within the SIP URL would fix that. > > user=lrn is almost right. If you have queried a portable number and > found that it is not ported, then the DN has the same status as an LRN > would have if the number were ported (i.e. it should be treated as > authoritative for routing). user=np-queried might be closer to the > mark. I wonder if we can't think about this problem in more general terms. In the SIP model, each proxy owns some piece of the namespace (engineering.dynamicsoft.com, for example), and is therefore responsible for the definition of the user space (jdrosen@) within that domain. Thats why each proxy can, an usually will, perform some kind of URI translation independent from other proxies. Our underlying assumption was that usernames only have meaning within their domain. For example, with sip:jdrosen@dynamicsoft.com, only a dynamicsoft.com proxy knows how to handle jdrosen. There might be jdrosen's in other domains that aren't me. However, in the case of telephone numbers, the proxy that owns the domain does not necessarily own the user space. sip:5551212@gateway.com, for example, uses a user name that is not "owned" by gateway.com, in the sense that this name has valid semantics outside of gateway.com. Other domains, like wcom.com, would know how to handle this number as well. Its possible that we might even see things besides phone numbers as user names that are valid across multiple domains. An example is (heaven forbid), social security numbers (in the US, at least): sip:123-45-6789@wcom.com;user=ssn Now, I might imagine that some kind of mobility services might be supplied for these names, so they might need to be translated also. I'll call these type of user names "cross domain user names". With cross domain user names, this is where we run into issues like "has the number been queried yet". However, I think we might see other translation mechanisms besides LNP. Soooo, might it not be useful to define URI parameters that indicate what global translation services have been applied to a cross domain user name? As an example: sip:15551212@cisco.com;user=phone;trans="lnp,gdbs" where lnp and gdbs are some kind of global translation services that apply to names of the type phone. For cross domain user names, we will always need a URI parameter to indicate the global namespace from which these names are drawn. In the case of phone numbers, thats user=phone. Our original intent with the user=phone parameter was to specify only the type of BNF used for the user part of the URI. But, the more general operation of specifying both the format and the namespace seems useful. > > It's also necessary to define what the TRIP should do differently > depending on whether the np-queried indication is present. I must > admit I came into this discussion mainly because I have worked on > LNP. I assume the objective is not to route unqueried calls to the > donor proxy. Hmm. This is something thats also different from the PSTN. The cost of routing to the donor proxy in SIP is much less, since proxies can be stateless. Thus, if a proxy receives a call for some number that is ported, it stateless proxies the call towards the next destination. The result is that there is no triangle routing for media (there generally isn't), nor for subsequent signaling. There is only marginal cost for the donor provider. There are obviously polticial and business issues; one may not want to trust or rely upon the donor proxy at all, as is the case of LNP in the US. But, the general SIP model is that we assume proxies do route calls; no security measures can prevent a proxy from dropping messages. Why, in the case of LNP, do we now need to assume these proxies won't route calls? I have noted that originator query may not be practical > for nationwide calling and that donor proxy is too late unless you're > prepared to consider RTP. The assumption of the impractability of originator queries has everything to do with the existing structure of LNP. Its mainly because, AFAIK, the systems are different all over the world. However, if we use the IP model, with a DNS solution, its no harder to query for a number on the other side of the planet as it would be for a number next door. Also, pardon my ignorance, but what is RTP? Many of us on this list know RTP as the Real Time Transport Protocol (rfc1889) but I don't think thats what you mean. One answer might be for the TRIP to provide > a response on unqueried numbers that routes to an intermediate server > that does know how to do NP queries for the destination DN. TRIP is not a query protocol. Its a routing protocol. This would be a SIP function, and is already possible. "408 Not Found". -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:53:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29008 for ; Mon, 8 May 2000 23:53:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA3C54446C; Mon, 8 May 2000 16:27:26 -0400 (EDT) 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 8316044495 for ; Mon, 8 May 2000 16:25:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:31:16 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 70B444438F; Mon, 8 May 2000 14:21:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 49E2644383 for ; Mon, 8 May 2000 14:21:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 34AF552AB; Mon, 8 May 2000 14:21:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 6290852B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id HAA19848 for ; Mon, 8 May 2000 07:56:15 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 07:54:51 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:54:50 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA252656; Mon, 8 May 2000 21:49:43 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA31476; Mon, 8 May 2000 21:54:42 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.00416E60 ; Mon, 8 May 2000 21:54:40 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Alan Johnston Cc: Rohan Mahy , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:17 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: I-D ACTION:draft-ietf-sip-call-flows-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Alan Johnston wrote: > > Rohan, > > You are correct - the Session:Media header is missing from all 183 responses in > the document. That will be fixed - thanks for pointing this out. > > I think the sequence of PRACKs and 200 OKs in scenario 4.1.2 (page 84) is > correct. PRACK is an end-to-end not hop-by-hop method (see Section 3 of > draft-ietf-sip-100rel), so the 200 OK response to it is generated by GW 1 and > forwarded by Proxy 1. This is why there is no requirement that proxies support > the reliable response feature, but both User Agents must support it. Correct. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 8 23:54:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29022 for ; Mon, 8 May 2000 23:54:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D0E344471; Mon, 8 May 2000 16:14:09 -0400 (EDT) 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 2CC8944463 for ; Mon, 8 May 2000 16:13:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 16:18:07 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A4E8D44389; Mon, 8 May 2000 14:21:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 6DDF644383 for ; Mon, 8 May 2000 14:21:04 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B8A0152B6; Mon, 8 May 2000 14:21:03 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id DF12252BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20413 for ; Mon, 8 May 2000 08:10:48 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:57:11 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 07:57:07 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA27868; Mon, 8 May 2000 21:51:15 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA51386; Mon, 8 May 2000 21:56:31 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.004198A3 ; Mon, 8 May 2000 21:56:29 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: IETF SIP Cc: Jonathan Rosenberg , Joerg Ott Message-ID: Date: Mon, 8 May 2000 14:10:20 +0530 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=voDjdDiwQqn6LzsM46j4sEevsauAMQStGOwMDhSDMQn4Fjc6FPsNL2ft" Content-Disposition: inline Subject: [SIP] Draft agenda SIP WG published Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --0__=voDjdDiwQqn6LzsM46j4sEevsauAMQStGOwMDhSDMQn4Fjc6FPsNL2ft Content-type: text/plain; charset=us-ascii Content-Disposition: inline The draft agenda for Adelaide is at http://www.softarmor.com/sipwg/meets/IETF47/agenda.html with HTML attached for those of you who are web-deprived. If you see any glaring errors, please let Jonathan, Joerg, and I know ASAP. It's due at noon later today. I hope most of my errors were caught in my requests for feedback on the agenda request list. -- Dean Willis SIP WG cochair --0__=voDjdDiwQqn6LzsM46j4sEevsauAMQStGOwMDhSDMQn4Fjc6FPsNL2ft Content-type: text/html; name="Agenda, IETF 47, SIP WG.htm" Content-Disposition: attachment; filename="Agenda, IETF 47, SIP WG.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjwhLS0gc2F2ZWQgZnJvbSB1cmw9KDAwNTUpaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29t L3NpcHdnL21lZXRzL0lFVEY0Ny9hZ2VuZGEuaHRtbCAtLT4NCjxIVE1MPjxIRUFEPjxUSVRMRT5B Z2VuZGEsIElFVEYgNDcsIFNJUCBXRzwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9d2luZG93cy0xMjUyIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNv bnRlbnQ9Ik1TSFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJP RFk+DQo8SDE+QWdlbmRhLCBJRVRGIDQ3IFNJUCBXRyBTZXNzaW9uIChEcmFmdCk8L0gxPg0KPFA+ UHJvcG9zZWQgZHJhZnQgcGVuZGluZyBjaGFpciByZXZpZXcuPC9QPg0KPEhSPg0KDQo8UD48U1RS T05HPk1vbmRheSwgTWFyY2ggMjcsIDIwMDA8QlI+MDkzMCAtIDExMzA8L1NUUk9ORz48L1A+DQo8 VEFCTEUgYm9yZGVyPTEgaGVpZ2h0PTQ4NiB3aWR0aD0iMTAwJSI+DQogIDxUQk9EWT4NCiAgPFRS Pg0KICAgIDxURCBoZWlnaHQ9MTkgd2lkdGg9IjIwJSI+PFNUUk9ORz48VT5QcmVzZW50ZXI8L1U+ PC9TVFJPTkc+PC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSI0NSUiPjxTVFJPTkc+PFU+ VGl0bGU8L1U+PC9TVFJPTkc+PC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSIxMCUiPjxT VFJPTkc+PFU+VGltZTwvVT48L1NUUk9ORz48L1REPg0KICAgIDxURCBoZWlnaHQ9MTkgd2lkdGg9 IjI1JSI+PFNUUk9ORz48VT5Db250YWN0PC9VPjwvU1RST05HPjwvVEQ+PC9UUj4NCiAgPFRSPg0K ICAgIDxURCBoZWlnaHQ9MTkgd2lkdGg9IjIwJSI+Q2hhaXJzPC9URD4NCiAgICA8VEQgaGVpZ2h0 PTE5IHdpZHRoPSI0NSUiPkFnZW5kYSBCYXNoaW5nPC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdp ZHRoPSIxMCUiPjA5MzA8QlI+MDo1PC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSIyNSUi PmRlYW4ud2lsbGlzQHdjb20uY29tPC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0x OSB3aWR0aD0iMjAlIj5DaGFpcnM8L1REPg0KICAgIDxURCBoZWlnaHQ9MTkgd2lkdGg9IjQ1JSI+ TWlsZXN0b25lIFN0YXR1cw0KICAgICAgPFRBQkxFPg0KICAgICAgICA8VEJPRFk+DQogICAgICAg IDxUUj4NCiAgICAgICAgICA8VEQgdkFsaWduPXRvcCB3aWR0aD03MD5Hb2FsLzxCUj5TdGF0dXM8 L1REPg0KICAgICAgICAgIDxURD48L1REPg0KICAgICAgICAgIDxURD5UYXNrPC9URD48L1RSPg0K ICAgICAgICA8VFIgYWxpZ249bGVmdCB2QWxpZ249dG9wPg0KICAgICAgICAgIDxURCB2QWxpZ249 dG9wIHdpZHRoPTcwPkRlYyA5OTxCUj5GZWIgMDA8L1REPg0KICAgICAgICAgIDxURD4mbmJzcDsm bmJzcDs8L1REPg0KICAgICAgICAgIDxURD5JTkZPIE1ldGhvZCBleHRlbnNpb24gc3VibWl0dGVk IHRvIElFU0cgPC9URD48L1RSPg0KICAgICAgICA8VFIgYWxpZ249bGVmdCB2QWxpZ249dG9wPg0K ICAgICAgICAgIDxURCB2QWxpZ249dG9wIHdpZHRoPTcwPkZlYiAwMDxCUj5Tb29uPC9URD4NCiAg ICAgICAgICA8VEQ+Jm5ic3A7Jm5ic3A7PC9URD4NCiAgICAgICAgICA8VEQ+RWFybHkgc2Vzc2lv biBlc3RhYmxpc2htZW50IGV4dGVuc2lvbiBzdWJtaXR0ZWQgdG8gSUVTRzwvVEQ+PC9UUj4NCiAg ICAgICAgPFRSIGFsaWduPWxlZnQgdkFsaWduPXRvcD4NCiAgICAgICAgICA8VEQgdkFsaWduPXRv cCB3aWR0aD03MD5NYXIgMDA8QlI+U29vbjwvVEQ+DQogICAgICAgICAgPFREPiZuYnNwOyZuYnNw OzwvVEQ+DQogICAgICAgICAgPFREPkNhbGxlciBwcmVmZXJlbmNlcyBzcGVjaWZpY2F0aW9uIHN1 Ym1pdHRlZCB0byBJRVNHPC9URD48L1RSPg0KICAgICAgICA8VFIgYWxpZ249bGVmdCB2QWxpZ249 dG9wPg0KICAgICAgICAgIDxURCB2QWxpZ249dG9wIHdpZHRoPTcwPk1heSAwMDxCUj5PcGVuPC9U RD4NCiAgICAgICAgICA8VEQ+Jm5ic3A7Jm5ic3A7PC9URD4NCiAgICAgICAgICA8VEQ+Q2FsbCBj b250cm9sIHNwZWNpZmljYXRpb24gc3VibWl0dGVkIHRvIElFU0c8L1REPjwvVFI+DQogICAgICAg IDxUUiBhbGlnbj1sZWZ0IHZBbGlnbj10b3A+DQogICAgICAgICAgPFREIHZBbGlnbj10b3Agd2lk dGg9NzA+SnVsIDAwPEJSPk9wZW48L1REPg0KICAgICAgICAgIDxURD4mbmJzcDsmbmJzcDs8L1RE Pg0KICAgICAgICAgIDxURD5EcmFmdCBzdGFuZGFyZCB2ZXJzaW9uIG9mIFNJUCBzdWJtaXR0ZWQg dG8gSUVTRzwvVEQ+PC9UUj4NCiAgICAgICAgPFRSIGFsaWduPWxlZnQgdkFsaWduPXRvcD4NCiAg ICAgICAgICA8VEQgdkFsaWduPXRvcCB3aWR0aD03MD5KdWwgMDA8QlI+b3BlbjwvVEQ+DQogICAg ICAgICAgPFREPiZuYnNwOyZuYnNwOzwvVEQ+DQogICAgICAgICAgPFREPlNJUCBNSUIgc3VibWl0 dGVkIHRvIElFU0c8L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvVEQ+DQogICAgPFREIGhlaWdo dD0xOSB3aWR0aD0iMTAlIj4wOTM1PEJSPjA6NTwvVEQ+DQogICAgPFREIGhlaWdodD0xOSB3aWR0 aD0iMjUlIj5kZWFuLndpbGxpc0B3Y29tLmNvbTwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBo ZWlnaHQ9MTkgd2lkdGg9IjIwJSI+Q2hhaXJzPC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRo PSI0NSUiPkNoYXJ0ZXIgRGlzY3Vzc2lvbjxCUj5Db25zaWRlciBhcyBXRyBpdGVtcywgc2V0IA0K ICAgICAgbWlsZXN0b25lcyBmb3I6DQogICAgICA8VUw+DQogICAgICAgIDxMST5TSVAgU2VydmVy IEZlYXR1cmVzIE5lZ290aWF0aW9uIA0KICAgICAgICA8TEk+Q2FsbCBGbG93cyAoSW5mb3JtYXRp b25hbCkgDQogICAgICAgIDxMST5TSVAgU2Vzc2lvbiBUaW1lciANCiAgICAgICAgPExJPlJlbGlh YmlsaXR5IGZvciBQcm92aXNpb25hbCBNZXNzYWdlcyANCiAgICAgICAgPExJPlNJUC1UZWxlcGhv bnkgDQogICAgICAgIDxMST5Db252ZXJnZW5jZSB3aXRoIHRoZSBQYWNrZXRDYWJsZSBEQ1MgU3Bl YyAoPEEgDQogICAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy90ZWFt cy9zaXBkY3MvaW5kZXguaHRtbCI+RENTIA0KICAgICAgICBUZWFtPC9BPikgDQogICAgICAgIDxM ST5TZWN1cml0eSANCiAgICAgICAgPExJPlNpbmdsZSBMaW5lIEV4dGVuc2lvbiZuYnNwOyA8L0xJ PjwvVUw+PC9URD4NCiAgICA8VEQgaGVpZ2h0PTE5IHdpZHRoPSIxMCUiPjA5NDU8QlI+MDoxNTwv VEQ+DQogICAgPFREIGhlaWdodD0xOSB3aWR0aD0iMjUlIj5kZWFuLndpbGxpc0B3Y29tLmNvbTwv VEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjIwJSI+Sm9uYXRoYW4g Um9zZW5iZXJnPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUiPldHIHN0YXR1cyBh bmQgY3VycmVudCBsaXN0IHRvcGljczxCUj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29m dGFybW9yLmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtbmFpci1zaXAtZGhjcC0wMC50eHQiPmRyYWZ0 LW5haXItc2lwLWRoY3AtMDAudHh0PC9BPjxCUj5vdGhlciANCiAgICAgIHN0dWZmIGZyb20gbGlz dDwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMTAlIj4xMDAwPEJSPjA6MTU8L1REPg0K ICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJtYWlsdG86amRy b3NlbkBkeW5hbWljc29mdC5jb20iPmpkcm9zZW5AZHluYW1pY3NvZnQuY29tPC9BPjwvVEQ+PC9U Uj4NCiAgPFRSPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjIwJSI+Sm9uYXRoYW4gUm9zZW5i ZXJnIDwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhyZWY9 Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtaWV0Zi1zaXAtY2Fs bGVycHJlZnMtMDEudHh0Ij5kcmFmdC1pZXRmLXNpcC1jYWxsZXJwcmVmcy0wMS50eHQ8L0E+PEJS PldHIA0KICAgICAgY2hhcnRlciBpdGVtLCByZXZpZXcgY2hhbmdlcywgbm8gb3BlbiBpc3N1ZXMs IHBsYW4gdG8gbGFzdCBjYWxsIGZvbGxvd2luZyANCiAgICAgIHNlc3Npb24gdGltZXIgYW5kIHJl bGlhYmxlIHByb3Zpc2lvbmFsLCBzY2hlZHVsZSBjcml0aWNhbDwvVEQ+DQogICAgPFREIGhlaWdo dD0zOCB3aWR0aD0iMTAlIj4xMDE1PEJSPjA6MTA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lk dGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJtYWlsdG86amRyb3NlbkBkeW5hbWljc29mdC5jb20i Pmpkcm9zZW5AZHluYW1pY3NvZnQuY29tPC9BPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBo ZWlnaHQ9Mzggd2lkdGg9IjIwJSI+U3RldmUgRG9ub3ZhbjwvVEQ+DQogICAgPFREIGhlaWdodD0z OCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9z aXB3Zy9kcmFmdHMvZHJhZnQtaWV0Zi1zaXAtaW5mby1tZXRob2QtMDEudHh0Ij5kYXJmdC1pZXRm LXNpcC1pbmZvLW1ldGhvZC0wMS50eHQ8L0E+PEJSPldHIA0KICAgICAgY2hhcnRlciBpdGVtLCBJ RVNHLCBsYXN0IGNhbGwgc2NoZWR1bGVkIDMvMTg8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lk dGg9IjEwJSI+MTAyNTxCUj4wOjA1PC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyNSUi PjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOlN0ZXZlbi5SLkRvbm92YW5Ad2NvbS5jb20iPlN0ZXZl bi5SLkRvbm92YW5Ad2NvbS5jb208L0E+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdo dD0zOCB3aWR0aD0iMjAlIj5TdGV2ZSBEb25vdmFuPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdp ZHRoPSI0NSUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdn L2RyYWZ0cy9kcmFmdC1pZXRmLXNpcC0xODMtMDAudHh0Ij5kcmFmdC1pZXRmLXNpcC0xODMtMDAu dHh0PC9BPiANCiAgICAgIChvbGQgZHJhZnQpPEJSPldHIGNoYXJ0ZXIgaXRlbSwgcmV2aWV3IHN0 YXR1cywgaXNzdWVzPEJSPlNjaGVjZHVsZSANCiAgICBjcml0aWNhbDwvVEQ+DQogICAgPFREIGhl aWdodD0zOCB3aWR0aD0iMTAlIj4xMDMwPEJSPjA6MDU8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzgg d2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJtYWlsdG86U3RldmVuLlIuRG9ub3ZhbkB3Y29t LmNvbSI+U3RldmVuLlIuRG9ub3ZhbkB3Y29tLmNvbTwvQT48L1REPjwvVFI+DQogIDxUUj4NCiAg ICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyMCUiPkpvbmF0aGFuIFJvc2VuYmVyZzwvVEQ+DQogICAg PFREIGhlaWdodD0zOCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29m dGFybW9yLmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtaWV0Zi1zaXAtc2VydmVyZmVhdHVyZXMtMDIu dHh0Ij5kcmFmdC1pZXRmLXNpcC1zZXJ2ZXJmZWF0dXJlcy0wMi50eHQ8L0E+PEJSPlByb3Bvc2Vk IA0KICAgICAgV0cgY2hhcnRlciBpdGVtLCByZWFkeSBmb3IgSUVTRzwvVEQ+DQogICAgPFREIGhl aWdodD0zOCB3aWR0aD0iMTAlIj4xMDM1PEJSPjA6MTA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzgg d2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJtYWlsdG86amRyb3NlbkBkeW5hbWljc29mdC5j b20iPmpkcm9zZW5AZHluYW1pY3NvZnQuY29tPC9BPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxU RCBoZWlnaHQ9Mzggd2lkdGg9IjIwJSI+Sm9uYXRoYW4gUm9zZW5iZXJnPC9URD4NCiAgICA8VEQg aGVpZ2h0PTM4IHdpZHRoPSI0NSUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJt b3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1pZXRmLXNpcC0xMDByZWwtMDAudHh0Ij5kcmFmdC1p ZXRmLXNpcC0xMDByZWwtMDAudHh0PC9BPjxCUj5Qcm9wb3NlZCANCiAgICAgIFdHIGNoYXJ0ZXIg aXRlbSwgcmV2aWV3IG9wZW4gaXNzdWVzLCBtb3ZlIHF1aWNrbHk8L1REPg0KICAgIDxURCBoZWln aHQ9Mzggd2lkdGg9IjEwJSI+MTA0NTxCUj4wOjEwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdp ZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmpkcm9zZW5AZHluYW1pY3NvZnQuY29t Ij5qZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbTwvQT48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQg aGVpZ2h0PTM4IHdpZHRoPSIyMCUiPkpvbmF0aGFuIFJvc2VuYmVyZzwvVEQ+DQogICAgPFREIGhl aWdodD0zOCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9y LmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtcm9zZW5iZXJnLXNpcC1ndWlkZWxpbmVzLTAwLnR4dCI+ ZHJhZnQtcm9zZW5iZXJnLXNpcC1ndWlkZWxpbmVzLTAwLnR4dDwvQT48QlI+UXVlc3Rpb246IA0K ICAgICAgSW50ZXJlc3QgaW4gQkNQIHRyYWNrIFdHIGVmZm9ydD88L1REPg0KICAgIDxURCBoZWln aHQ9Mzggd2lkdGg9IjEwJSI+MTA1NTxCUj4wOjEwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdp ZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmpkcm9zZW5AZHluYW1pY3NvZnQuY29t Ij5qZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbTwvQT48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQg aGVpZ2h0PTM4IHdpZHRoPSIyMCUiPkpvbmF0aGFuIFJvc2VuYmVyZzwvVEQ+DQogICAgPFREIGhl aWdodD0zOCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc29mdGFybW9y LmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtcm9zZW5iZXJnLXNpcC0zcGNjLTAwLnR4dCI+ZHJhZnQt cm9zZW5iZXJnLXNpcC0zcGNjLTAwLnR4dDwvQT48QlI+dGhyZWUtcGFydHkgDQogICAgICBjYWxs IGNvbnRyb2wsIFF1ZXN0aW9uOiBXRyB0YXNrPzwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0 aD0iMTAlIj4xMTA1PEJSPjA6MTA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjI1JSI+ PEEgDQogICAgICBocmVmPSJtYWlsdG86amRyb3NlbkBkeW5hbWljc29mdC5jb20iPmpkcm9zZW5A ZHluYW1pY3NvZnQuY29tPC9BPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBoZWlnaHQ9Mzgg d2lkdGg9IjIwJSI+RGF2ZSBXYWxrZXI8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1 JSI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRz L2RyYWZ0LWlldGYtc2lwLW1pYi0wMC50eHQiPmRyYWZ0LWlldGYtc2lwLW1pYi0wMC50eHQ8L0E+ PEJSPldHIA0KICAgICAgQ2hhcnRlciBpdGVtPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRo PSIxMCUiPjExMTU8QlI+MDoxNTwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjUlIj48 QSANCiAgICAgIGhyZWY9Im1haWx0bzpkcndhbGtlckBzczhuZXR3b3Jrcy5jb20iPmRyd2Fsa2Vy QHNzOG5ldHdvcmtzLmNvbTwvQT48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgaGVpZ2h0PTM4 IHdpZHRoPSIyMCUiPkNoYWlyczwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iNDUlIj5X cmFwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIxMCUiPjExMzA8L1REPg0KICAgIDxU RCBoZWlnaHQ9Mzggd2lkdGg9IjI1JSI+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT4NCjxQPiZu YnNwOzwvUD4NCjxQPjxTVFJPTkc+VHVlc2RheSwgTWFyY2ggMjgsIDIwMDA8QlI+MTMwMC0xNTE1 PC9TVFJPTkc+PC9QPg0KPFRBQkxFIGJvcmRlcj0xIGhlaWdodD05NCB3aWR0aD0iMTAwJSI+DQog IDxUQk9EWT4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD0iMjAlIj48U1RST05HPjxVPlByZXNlbnRl cjwvVT48L1NUUk9ORz48L1REPg0KICAgIDxURCB3aWR0aD0iNDUlIj48U1RST05HPjxVPlRpdGxl PC9VPjwvU1RST05HPjwvVEQ+DQogICAgPFREIHdpZHRoPSIxMCUiPjxTVFJPTkc+PFU+VGltZTwv VT48L1NUUk9ORz48L1REPg0KICAgIDxURCB3aWR0aD0iMjUlIj48U1RST05HPjxVPkNvbnRhY3Q8 L1U+PC9TVFJPTkc+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIHdpZHRoPSIyMCUiPkNoYWly czwvVEQ+DQogICAgPFREIHdpZHRoPSI0NSUiPkludHJvIGFuZCBBZ2VuZGE8L1REPg0KICAgIDxU RCB3aWR0aD0iMTAlIj4xMzAwPEJSPjA6NTwvVEQ+DQogICAgPFREIHdpZHRoPSIyNSUiPmRlYW4u d2lsbGlzQHdjb20uY29tPC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0 aD0iMjAlIj5Sb2JlcnQgU3BhcmtzPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUi PjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9k cmFmdC1jYW1wYmVsbC1zaXAtY2MtZnJhbWV3b3JrLTAwLnR4dCI+ZHJhZnQtY2FtcGJlbGwtc2lw LWNjLWZyYW1ld29yay0wMC50eHQ8L0E+PEJSPldHIA0KICAgICAgQ2hhcnRlciBJdGVtLCBTdGF0 dXMgQ3JpdGljYWw8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjEwJSI+MTMwNTxCUj4w OjE1PC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0i bWFpbHRvOnJvYmVydC5zcGFya3NAd2NvbS5jb20iPnJvYmVydC5zcGFya3NAd2NvbS5jb208L0E+ PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5Sb2JlcnQg U3BhcmtzPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUiPjxBIA0KICAgICAgaHJl Zj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1zcGFya3Mtc2lw LWNjLXRyYW5zZmVyLTAwLnR4dCI+ZHJhZnQtc3BhcmtzLXNpcC1jYy10cmFuc2Zlci0wMC50eHQ8 L0E+PEJSPldHIA0KICAgICAgQ2hhcnRlciBJdGVtLCBTdGF0dXMgQ3JpdGljYWw8L1REPg0KICAg IDxURCBoZWlnaHQ9Mzggd2lkdGg9IjEwJSI+MTMyMDxCUj4wOjEwPC9URD4NCiAgICA8VEQgaGVp Z2h0PTM4IHdpZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOnJvYmVydC5zcGFya3NA d2NvbS5jb20iPnJvYmVydC5zcGFya3NAd2NvbS5jb208L0E+PC9URD48L1RSPg0KICA8VFI+DQog ICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5UQkQ8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzgg d2lkdGg9IjQ1JSI+U0lQLVQgU3RhdHVzIFJlcG9ydDwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3 aWR0aD0iMTAlIj4xMzM1PEJSPjA6NTwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjUl Ij5UQkQ8L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyMCUiPkdv bnphbG8gQ2FtYXJpbGxvPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUiPjxBIA0K ICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1j YW1hcmlsbG8tc2lwLWlzdXAtYmNwLTAwLnR4dCI+ZHJhZnQtY2FtYXJpbGxvLXNpcC1pc3VwLWJj cC0wMC50eHQ8L0E+PEJSPlByb3Bvc2VkIA0KICAgICAgV0cgY2hhcnRlciBpdGVtPzwvVEQ+DQog ICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMTAlIj4xMzQwPEJSPjA6MTA8L1REPg0KICAgIDxURCBo ZWlnaHQ9Mzggd2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJtYWlsdG86Z29uemFsby5jYW1h cmlsbG9AZXJjaWNzc29uLmNvbSI+Z29uemFsby5jYW1hcmlsbG9AZXJjaWNzc29uLmNvbTwvQT48 L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyMCUiPlN0ZXZlIERv bm92YW48L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1JSI+PEEgDQogICAgICBocmVm PSJodHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LWlldGYtc2lwLXNl c3Npb24tdGltZXItMDEudHh0Ij5kcmFmdC1pZXRmLXNpcC1zZXNzaW9uLXRpbWVyLTAxLnR4dDwv QT48QlI+UHJvcG9zZWQgDQogICAgICBXRyBjaGFydGVyIGl0ZW0sIHJldmlldyBjaGFuZ2VzLCBp c3N1ZXMsIG1vdmUgcXVpY2s8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjEwJSI+MTM1 MDxCUj4wOjEwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyNSUiPjxBIA0KICAgICAg aHJlZj0ibWFpbHRvOlN0ZXZlbi5SLkRvbm92YW5Ad2NvbS5jb20iPlN0ZXZlbi5SLkRvbm92YW5A d2NvbS5jb208L0E+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0i MjAlIj5KYW1lcyBQb2xrPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUiPjxBIA0K ICAgICAgaHJlZj0iaHR0cDovL3d3dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1w b2xrLXNpcC1tbHBwLW1hcHBpbmctMDAudHh0Ij5kcmFmdC1wb2xrLXNpcC1tbHBwLW1hcHBpbmct MDAudHh0PC9BPjwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMTAlIj4xNDAwPEJSPjA6 MTU8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJt YWlsdG86am1wb2xrQGNpc2NvLmNvbSI+am1wb2xrQGNpc2NvLmNvbTwvQT4gPC9URD48L1RSPg0K ICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5BZGFtIFJvYWNoPC9URD4NCiAg ICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5z b2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1yb2FjaC1zaXAtc3Vic2NyaWJlLW5vdGlm eS0wMC50eHQiPmRyYWZ0LXJvYWNoLXNpcC1zdWJzY3JpYmUtbm90aWZ5LTAwLnR4dDwvQT48L1RE Pg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjEwJSI+MTQxNTxCUj4wOjEwPC9URD4NCiAgICA8 VEQgaGVpZ2h0PTM4IHdpZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmFkYW0ucm9h Y2hAZXJpY3Nzb24uY29tIj5hZGFtLnJvYWNoQGVyaWNzc29uLmNvbTwvQT48L1REPjwvVFI+DQog IDxUUj4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyMCUiPkhlbnJ5IFNpbm5yZWljaCA8L1RE Pg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1JSI+PEEgDQogICAgICBocmVmPSJodHRwOi8v d3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LXNpbm5yZWljaC1zaXAtcW9zLW9z cC0wMS50eHQiPmRyYWZ0LXNpbm5yZWljaC1zaXAtcW9zLW9zcC0wMS50eHQ8L0E+PC9URD4NCiAg ICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIxMCUiPjE0MjU8QlI+MDoxNTwvVEQ+DQogICAgPFREIGhl aWdodD0zOCB3aWR0aD0iMjUlIj48QSANCiAgICAgIGhyZWY9Im1haWx0bzpoZW5yeS5zaW5ucmVp Y2hAd2NvbS5jb20iPmhlbnJ5LnNpbm5yZWljaEB3Y29tLmNvbTwvQT48L1REPjwvVFI+DQogIDxU Uj4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyMCUiPkpvbmF0aGFuIFJvc2VuYmVyZzwvVEQ+ DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93 d3cuc29mdGFybW9yLmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtbGVubm94LXNpcC1yZWctcGF5bG9h ZC0wMC50eHQiPmRyYWZ0LWxlbm5veC1zaXAtcmVnLXBheWxvYWQtMDAudHh0PC9BPjwvVEQ+DQog ICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMTAlIj4xNDQwPEJSPjA6MTU8L1REPg0KICAgIDxURCBo ZWlnaHQ9Mzggd2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJtYWlsdG86amRyb3NlbkBkeW5h bWljc29mdC5jb20iPmpkcm9zZW5AZHluYW1pY3NvZnQuY29tPC9BPjwvVEQ+PC9UUj4NCiAgPFRS Pg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjIwJSI+Sm9uYXRoYW4gUm9zZW5iZXJnPC9URD4N CiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSI0NSUiPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3 dy5zb2Z0YXJtb3IuY29tL3NpcHdnL2RyYWZ0cy9kcmFmdC1yb3NlbmJlcmctc2lwLWZpcmV3YWxs cy0wMC50eHQiPmRyYWZ0LXJvc2VuYmVyZy1zaXAtZmlyZXdhbGxzLTAwLnR4dDwvQT48QlI+UXVl c3Rpb247IA0KICAgICAgSW50ZXJlc3QgaW4gaW5mbyB0cmFjayBXRyBlZmZvcnQ/PC9URD4NCiAg ICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIxMCUiPjE0NTU8QlI+MDoxNDwvVEQ+DQogICAgPFREIGhl aWdodD0zOCB3aWR0aD0iMjUlIj48QSANCiAgICAgIGhyZWY9Im1haWx0bzpqZHJvc2VuQGR5bmFt aWNzb2Z0LmNvbSI+amRyb3NlbkBkeW5hbWljc29mdC5jb208L0E+PC9URD48L1RSPg0KICA8VFI+ DQogICAgPFREIGhlaWdodD01NyB3aWR0aD0iMjAlIj5Kb25hdGhhbiBSb3NlbmJlcmc8L1REPg0K ICAgIDxURCBoZWlnaHQ9NTcgd2lkdGg9IjQ1JSI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3 LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LXJzLXRyaXAtZ3ctMDAudHh0Ij5kcmFm dC1ycy10cmlwLWd3LTAwLnR4dDwvQT48QlI+aW50cm8gDQogICAgICBvZiByZWxhdGVkIGRyYWZ0 IGZyb20gSVBURUw8L1REPg0KICAgIDxURCBoZWlnaHQ9NTcgd2lkdGg9IjEwJSI+MTUwOTxCUj4w OjE8L1REPg0KICAgIDxURCBoZWlnaHQ9NTcgd2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJt YWlsdG86amRyb3NlbkBkeW5hbWljc29mdC5jb20iPmpkcm9zZW5AZHluYW1pY3NvZnQuY29tPC9B PjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjIwJSI+Um9iZXJ0 IFNwYXJrczwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iNDUlIj48QSANCiAgICAgIGhy ZWY9Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXB3Zy9kcmFmdHMvZHJhZnQtY2FtcGJlbGwt c2lwLXNlcnZpY2UtY29udHJvbC0wMC50eHQiPmRyYWZ0LWNhbXBiZWxsLXNpcC1zZXJ2aWNlLWNv bnRyb2wtMDAudHh0PC9BPjwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMTAlIj4xNTEw PEJSPjA6NTwvVEQ+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjUlIj48QSANCiAgICAgIGhy ZWY9Im1haWx0bzpyb2JlcnQuc3BhcmtzQHdjb20uY28iPnJvYmVydC5zcGFya3NAd2NvbS5jbzwv QT48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyMCUiPkplZmYg TWFyayA8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1JSI+PEEgDQogICAgICBocmVm PSJodHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwd2cvZHJhZnRzL2RyYWZ0LW1hcmstc2lwLWRt Y3MtMDAudHh0Ij5kcmFmdC1tYXJrLXNpcC1kbWNzLTAwLnR4dDwvQT48L1REPg0KICAgIDxURCBo ZWlnaHQ9Mzggd2lkdGg9IjEwJSI+MTUxNTxCUj4wOjEwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4 IHdpZHRoPSIyNSUiPjxBIA0KICAgICAgaHJlZj0ibWFpbHRvOltKZWZmLk1hcmtARGlhbG9naWMu Y29tIj5tYWlsdG86W0plZmYuTWFya0BEaWFsb2dpYy5jb208L0E+PC9URD48L1RSPg0KICA8VFI+ DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5TaGluaWNoaSBCYWJhIDwvVEQ+DQogICAg PFREIGhlaWdodD0zOCB3aWR0aD0iNDUlIj5kcmFmdC1pdHN1bW8tc2lwLW1vYmlsaXR5LXJlcS0w MC50eHQ8L1REPg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjEwJSI+MTUyNTxCUj4wOjU8L1RE Pg0KICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjI1JSI+PEEgDQogICAgICBocmVmPSJtYWlsdG86 c2JhYmFAdGFyaS50b3NoaWJhLmNvbSI+c2JhYmFAdGFyaS50b3NoaWJhLmNvbTwvQT4gPC9URD48 L1RSPg0KICA8VFI+DQogICAgPFREIGhlaWdodD0zOCB3aWR0aD0iMjAlIj5DaGFpcnM8L1REPg0K ICAgIDxURCBoZWlnaHQ9Mzggd2lkdGg9IjQ1JSI+V3JhcDwvVEQ+DQogICAgPFREIGhlaWdodD0z OCB3aWR0aD0iMTAlIj4xNTMwPC9URD4NCiAgICA8VEQgaGVpZ2h0PTM4IHdpZHRoPSIyNSUiPjwv VEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+DQo8SFI+DQoNCjxQPlJldmlzZWQgPCEtLXdlYmJvdCBi b3Q9IlRpbWVzdGFtcCIgUy1UeXBlPSJFRElURUQiIFMtRm9ybWF0PSIlQiAlZCwgJVkgJUg6JU0i IHN0YXJ0c3BhbiAtLT5NYXJjaCANCjE3LCAyMDAwIDE4OjU3PCEtLXdlYmJvdCBib3Q9IlRpbWVz dGFtcCIgZW5kc3BhbiBpLWNoZWNrc3VtPSIyNjUyMyIgLS0+IA0KR01UPC9QPjwvQk9EWT48L0hU TUw+DQo= --0__=voDjdDiwQqn6LzsM46j4sEevsauAMQStGOwMDhSDMQn4Fjc6FPsNL2ft-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:57:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29104 for ; Mon, 8 May 2000 23:57:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EDC88443EB; Mon, 8 May 2000 15:34:04 -0400 (EDT) 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 D6222443EA for ; Mon, 8 May 2000 15:33:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon May 8 15:38:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3845B44372; Mon, 8 May 2000 14:20:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3002A44366 for ; Mon, 8 May 2000 14:20:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 07F0852C8; Mon, 8 May 2000 14:20:04 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 1DE4F52E9 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20448 for ; Mon, 8 May 2000 08:12:17 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:59:11 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:59:10 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA151548; Mon, 8 May 2000 21:53:18 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA64690; Mon, 8 May 2000 21:58:17 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041BF4A ; Mon, 8 May 2000 21:58:08 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com, cgi-wg@golux.com Cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com Message-ID: Date: Mon, 8 May 2000 14:10:23 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Informal Last Call: Common Gateway Interface for SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com With the submission of the most recent version of the SIP Common Gateway Interface, we'd like to announce an informal Last Call on this document (in place of a Working Group last call, since this draft has no associated working group). We'll solicit comments for four weeks, until March 31, 2000. At that time we'll submit this draft for Informational RFC status. Comments on the draft should be sent to the SIP mailing list sip@lists.research.bell-labs.com, or to the authors. Title : Common Gateway Interface for SIP Author(s) : J. Lennox, J. Rosenberg, H. Schulzrinne Filename : draft-lennox-sip-cgi-03.txt,.ps Pages : 38 Date : 02-Mar-00 In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the Common Gateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between the Session Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP), CGI seems a good candidate for service creation in a SIP environment. This draft proposes a SIP-CGI interface for providing SIP services on a SIP server. URLs for this Internet-Draft are: http://www.ietf.org/internet-drafts/draft-lennox-sip-cgi-03.txt http://www.ietf.org/internet-drafts/draft-lennox-sip-cgi-03.ps http://www.cs.columbia.edu/~lennox/draft-lennox-sip-cgi-03.pdf The Postscript and PDF versions contain changebars indicating changes from the previous version. -- Jonathan Lennox lennox@cs.columbia.edu --------- This message came from the IETF IPTEL Working Group Mailing List. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 8 23:59:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29115 for ; Mon, 8 May 2000 23:59:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4767244418; Mon, 8 May 2000 15:46:08 -0400 (EDT) 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 6A63544408 for ; Mon, 8 May 2000 15:45:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 15:51:45 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9E84E44373; Mon, 8 May 2000 14:20:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 2A80D4436E for ; Mon, 8 May 2000 14:20:16 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0ED8C52DD; Mon, 8 May 2000 14:20:11 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 0E81D52D5 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA20133 for ; Mon, 8 May 2000 08:02:20 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 07:57:34 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 07:57:33 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id VAA25958; Mon, 8 May 2000 21:52:26 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id VAA52884; Mon, 8 May 2000 21:57:25 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0041AE5B ; Mon, 8 May 2000 21:57:24 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: archow@hss.hns.com Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:26 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: SIP for PSTN services Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com archow@hss.hns.com wrote: > > Hi, > We need to use SIP to connect to PSTN side Fax, click to dial etc. > I read through the PINT draft which is supposeldy catering to this type of > service. > > However, I wanted to know which approach to select. Is PINT the standard > way for PSTN service interaction ? > It seems whatever PINT states can be done with regular SIP - or is that > incorrect PINT provides three specific functions - click-to-dial, click-to-fax, and click-for-content. It is not a general purpose protocol for PSTN service interaction. The scope of PSTN service interaction is sufficiently large that I think there will be many ways. For example, look at the recent SPIRITS working group. It is possible to do these three services with vanilla SIP. There are significant differences in how the service is delivered, though, with pros and cons for both approaches. A colleague and I submitted a draft on Friday entitled "Third Party Call Control in SIP", which looks at a general purpose SIP approach for third party call control (its not an extension, just a usage). One of the services discussed is click to dial, and there is a brief comparison to pint. I'm sure there are other ways of providing this service beyond pint and whats in the draft. Until it appears in the archives, you can pick up a copy of the draft at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-3pcc-00.txt > > And is my understanding that PINT is nothing but SIP/SDP with some > extensions and is analogous to the various SIP extensions drafts > that are in existence today ? Yes. PINT extends SDP more than SIP, since it describes sessions that are purely on the telephone network. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 9 00:01:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29193 for ; Tue, 9 May 2000 00:01:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A201F4452F; Mon, 8 May 2000 17:40:33 -0400 (EDT) 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 A9CA744563 for ; Mon, 8 May 2000 17:31:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:37:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 42069443C5; Mon, 8 May 2000 14:21:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1FDA1443AF for ; Mon, 8 May 2000 14:21:51 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7DB8B52AB; Mon, 8 May 2000 14:21:50 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id B710A52B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9] (may be forged)) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18281 for ; Mon, 8 May 2000 06:00:16 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon May 8 05:58:14 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:58:09 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA78778; Mon, 8 May 2000 19:53:00 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA46290; Mon, 8 May 2000 19:57:59 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036BE4B ; Mon, 8 May 2000 19:57:56 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Linden deCarmo Cc: "'Kundan Singh'" , "'Dean Willis'" , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:03 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: SIP & RTSP interworking? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Linden deCarmo wrote: > I like this a lot better, but the problem I have is this, we'd like for BOTH > sessions to be active at the same time and both of your proposals require a > teardown of the SIP session. > Linden, I still dont understand what the application is. Your first note said : ************* What I'd like to do is setup a session with SIP (via an INVITE), then control streaming aspects via RTSP (i.e. play, pause, stop etc.). ************* Implying to me that there was only one session. Your second note says: ************** I like this a lot better, but the problem I have is this, we'd like for BOTH sessions to be active at the same time and both of your proposals require a teardown of the SIP session. ************** Implying that there were two. (which I think makes sense). I think there are broadly two scenarios: a) Sending an RTSP URL to a SIP UA as part of redirection or call termination or transfer. The SIP session in question would be terminated. From the SIP point of view, it seems to make sense to put the RTSP URL in a Contact: or Also:, exact callflows and details to be worked out. b) Have a RTSP controlled stream as part of a conference ie an addon to an existing or about-to-exist SIP session. There could be a number of interesting variants to this. One of them that follows the "SIP-UA knows RTSP" model: You can have one SIP UA be the RTSP client (ie the owner/controller of the stream if you will), and direct the stream to each SIP UA in the session(could be via multicast as well). Other UAs dont need to know anything about RTSP. In which case SIP needs a way to inform UAs that this new RTP stream will be added to the session which I guess it should be able to do using re-INVITEs. If you go with the model that the RTSP server understands SIP, then RTSP provides a means to pass the conference ID to the RTSP server so that it can join the SIP session and link subsequent RTSP operations to the SIP session. Such IDs are opaque to RTSP protocol , so the usage would depend on the server and application in question. -Anup. > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > > -----Original Message----- > > From: Kundan Singh [SMTP:kns10@cs.columbia.edu] > > Sent: Wednesday, March 15, 2000 3:10 PM > > To: Linden deCarmo > > Cc: 'Dean Willis'; sip@lists.research.bell-labs.com > > Subject: RE: SIP & RTSP interworking? > > > > -- > > Kundan Singh http://www.cs.columbia.edu/~kns10 > > > > > This is an interesting suggestion, but the scenario I'm operating under > > is > > > this: > > > > > > UAC<->UAC (in this case the UAC really is an RTSP server), both must > > > understand SIP and RTSP. I need a way to tie the sessions between two > > > distinct protocols. Is a viable alternative to embed the RTSP SETUP > > message > > > as a SIP body for the INVITE? This would clearly associate the > > sessions, > > > but I hate to have a proprietary solution that wouldn't work with other > > > products that understood SIP & RTSP. > > > > In that case, the UA may return the RTSP Contact: URI in (say) 3xx > > response. > > > > UA1 UA2 > > INVITE > > --------------> > > > > 3xx Moved > > Contact:rtsp://server/resource > > <------------- > > > > SETUP rtsp://server/resource > > --------------> > > . . . > > > > Since UA here understand both SIP and RTSP it should not be > > a problem. > > > > If the SIP call is already established, and UA2 wants to > > switch to RTSP, then (IMO) it may use blind call transfer > > (BYE,Also:rtsp://...) to ask UA1 to connect to RTSP > > server of UA2. Comments ?? > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 00:03:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29214 for ; Tue, 9 May 2000 00:03:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7940844574; Mon, 8 May 2000 17:41:26 -0400 (EDT) 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 E4FAE44568 for ; Mon, 8 May 2000 17:31:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:37:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5FFBF443C2; Mon, 8 May 2000 14:21:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 31F87443AF for ; Mon, 8 May 2000 14:21:50 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 93DDB52AB; Mon, 8 May 2000 14:21:49 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 4C9A852BB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18418 for ; Mon, 8 May 2000 06:06:35 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:12 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:58:06 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA170132; Mon, 8 May 2000 19:52:58 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA51320; Mon, 8 May 2000 19:57:57 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036BCF4 ; Mon, 8 May 2000 19:57:53 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Jonathan Lennox Cc: Giuseppe Ricagni , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:03 +0530 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=6xvNhmaCO2SGZkd8yK3aMO4Tkt29fd4t6KbKPKDA6Ij1EqPESM2vz02e" Content-Disposition: inline Subject: [SIP] Re: Billing SIP proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --0__=6xvNhmaCO2SGZkd8yK3aMO4Tkt29fd4t6KbKPKDA6Ij1EqPESM2vz02e Content-type: text/plain; charset=us-ascii Content-Disposition: inline Jonathan, let me say that I' m a bit tired but, I'll try anyway... (forgive me if I say anything terribly wrong) Let' s even assume I can put each terminal behind a firewall, as you described (which is something that, in our architecture, might even be feasible): +---+ +------------+ | te1 |--------->|FW+Proxy1|------->+ +--+ +------------+ | | | +---+ +------------+ | | te2 |<---------|FW+Proxy2 |<-------+ +--+ +------------+ Now, by assumption, TE1 is hacked: I can do whatever I want with it. Well this network must be connected to the Internet: let's assume there is a firewall3 towards the Net. It is configured to let HTTP pass through as well as incoming INVITE and ACK messages (this is necessary to interoperate with the other PNOs). Now let me start my own business "freecalls Inc." (or, at least, "cut price calls inc...."), also selling terminals that * incapsulate SIP in HTTP ===> [FW+Proxy1] doesn't detect the INVITE nor the ACK * send the packetized voice via TCP to my magic server in the Net +---+ +------------+ | te1 |--------->|FW+Proxy1|--------+ +--+ +------------+ | |+-----+ +----------------------------+ | FW3 |--------->|Server (in the public Internet)+ +-----+ +----------------------------+ | | +---+ +------------+ | | te2 |<---------|FW+Proxy2 |--------+ +--+ +------------+ and that' s it: the server performs all the required translatons and sends all the SIP signalling and an RTP stream to TE2. Well, I have to admit it is not very optimized, but I designed it in half an hour.... .....I' sure our crowds of estimed hackers will be able to devise some much more efficient solutions.... Ciao Giuseppe P.S. 1st optimization: you said that "This, of course, forces you to provide application-level gateways for every UDP-using protocol your customers want to use." Instead of tunneling Firewall1 with HTTP+TCP, I could try with one of such UDP-based protocols... (much better !) Jonathan Lennox wrote: > On Tue, March 28 2000, "Giuseppe Ricagni" wrote to "sip@lists.research.bell-labs.com" saying: > > > during these days in Adelaide, I have already had the chance to discuss > > with some well known SIP experts about this topic, nevertheless I would > > like to pose the same question to the list: maybe someone has some other > > idea. > > > > Let' s assme that the scenaro is: > > > > * there are a number of "standard" SIP terminals, whose software is > > not modifiable by the user (nor any other application can be > > installed) > > * such SIP softare forces SIP to work in proxy mode > > * the proxy actually bills the calls > > > > Now let' s introduce a "hacked" terminal, and lets' s say that the > > software on such terminal is completely free, in the sense that whatever > > is needed we can modify it and install it. > > > > The question is: is it posible to define, to any extent, a mechanism > > capable of preventing the "hacked" terminal to bypass the proxy and call > > the "standard" endpoints witout being billed ? > > > > Please CC replies to gricagni@tin.it (it is easier for me to read email > > from such mailbox here in Adelaide) > > Put the terminals behind a firewall which doesn't allow random UDP packets > through. Have the SIP proxy tell the firewall to open up the ports for each > call's RTP streams after it processes the corresponding INVITE. Close them > when you see the BYE or when a session-timer expires (you'll need session > timers for this to work). > > This, of course, forces you to provide application-level gateways for every > UDP-using protocol your customers want to use. It also leads to the > question of why your customers won't just decamp to a provider who gives > them proper end-to-end IP service, and only bills for true value-added > features. > > -- > Jonathan Lennox > lennox@cs.columbia.edu --0__=6xvNhmaCO2SGZkd8yK3aMO4Tkt29fd4t6KbKPKDA6Ij1EqPESM2vz02e Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KSm9uYXRoYW4sDQo8cD5sZXQgbWUgc2F5IHRoYXQgSScgbSBhIGJpdCB0 aXJlZCZuYnNwOyBidXQsIEknbGwgdHJ5IGFueXdheS4uLiAoZm9yZ2l2ZQ0KbWUgaWYgSSBzYXkg YW55dGhpbmcgdGVycmlibHkgd3JvbmcpDQo8cD5MZXQnIHMgZXZlbiBhc3N1bWUgSSBjYW4gcHV0 IGVhY2ggdGVybWluYWwgYmVoaW5kIGEgZmlyZXdhbGwsIGFzIHlvdQ0KZGVzY3JpYmVkICh3aGlj aCBpcyBzb21ldGhpbmcgdGhhdCwgaW4gb3VyIGFyY2hpdGVjdHVyZSwgbWlnaHQgZXZlbiBiZQ0K ZmVhc2libGUpOg0KPHA+Ky0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCistLS0tLS0t LS0tLS0rDQo8YnI+fCB0ZTEgfC0tLS0tLS0tLT58RlcrUHJveHkxfC0tLS0tLS0+Kw0KPGJyPjx0 dD4rLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvdHQ+Ky0t LS0tLS0tLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCnwNCjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCnwNCjxicj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCnwNCjxi cj4rLS0tKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0tLS0tLS0tLS0tLSsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCnwNCjxicj58IHRlMiB8Jmx0Oy0tLS0tLS0tLXxGVytQcm94eTIgfCZsdDstLS0tLS0tKw0K PGJyPjx0dD4rLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv dHQ+Ky0tLS0tLS0tLS0tLSsNCjxicj4mbmJzcDsNCjxwPk5vdywgYnkgYXNzdW1wdGlvbiwgVEUx IGlzIGhhY2tlZDogSSBjYW4gZG8gd2hhdGV2ZXIgSSB3YW50IHdpdGggaXQuDQo8cD5XZWxsIHRo aXMgbmV0d29yayBtdXN0IGJlIGNvbm5lY3RlZCB0byB0aGUgSW50ZXJuZXQ6IGxldCdzIGFzc3Vt ZSB0aGVyZQ0KaXMgYSBmaXJld2FsbDMgdG93YXJkcyB0aGUgTmV0Lg0KPGJyPkl0IGlzIGNvbmZp Z3VyZWQgdG8gbGV0IEhUVFAgcGFzcyB0aHJvdWdoIGFzIHdlbGwgYXMgaW5jb21pbmcgSU5WSVRF DQphbmQgQUNLIG1lc3NhZ2VzICh0aGlzIGlzIG5lY2Vzc2FyeSB0byBpbnRlcm9wZXJhdGUgd2l0 aCB0aGUgb3RoZXIgUE5PcykuDQo8cD5Ob3cgbGV0IG1lIHN0YXJ0IG15IG93biBidXNpbmVzcyAi ZnJlZWNhbGxzIEluYy4iIChvciwgYXQgbGVhc3QsICJjdXQNCnByaWNlIGNhbGxzIGluYy4uLi4i KSwgYWxzbyBzZWxsaW5nJm5ic3A7IHRlcm1pbmFscyB0aGF0DQo8dWw+DQo8bGk+DQombmJzcDtp bmNhcHN1bGF0ZSBTSVAgaW4gSFRUUCA9PT0+IFtGVytQcm94eTFdIGRvZXNuJ3QgZGV0ZWN0IHRo ZSBJTlZJVEUNCm5vciB0aGUgQUNLPC9saT4NCg0KPGxpPg0KJm5ic3A7c2VuZCB0aGUgcGFja2V0 aXplZCB2b2ljZSB2aWEgVENQIHRvIG15IG1hZ2ljIHNlcnZlciBpbiB0aGUgTmV0PC9saT4NCjwv dWw+DQorLS0tKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0tLS0tLS0tLS0tLSsNCjxi cj58IHRlMSB8LS0tLS0tLS0tPnxGVytQcm94eTF8LS0tLS0tLS0rDQo8YnI+PHR0PistLSsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC90dD4rLS0tLS0tLS0tLS0t KyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KfA0KPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KfCstLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KfCBGVzMgfC0tLS0t LS0tLT58U2VydmVyIChpbiB0aGUgcHVibGljIEludGVybmV0KSsNCjxicj48dHQ+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQorLS0tLS0rJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvdHQ+Ky0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQp8DQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQp8DQo8YnI+Ky0tLSsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCistLS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQp8DQo8YnI+fCB0ZTIg fCZsdDstLS0tLS0tLS18RlcrUHJveHkyIHwtLS0tLS0tLSsNCjxicj48dHQ+Ky0tKyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3R0PistLS0tLS0tLS0tLS0rDQo8 YnI+Jm5ic3A7DQo8cD5hbmQgdGhhdCcgcyZuYnNwOyBpdDogdGhlIHNlcnZlciBwZXJmb3JtcyBh bGwgdGhlIHJlcXVpcmVkIHRyYW5zbGF0b25zDQphbmQgc2VuZHMgYWxsIHRoZSBTSVAgc2lnbmFs bGluZyBhbmQgYW4gUlRQIHN0cmVhbSB0byBURTIuDQo8cD5XZWxsLCBJIGhhdmUgdG8gYWRtaXQg aXQgaXMgbm90IHZlcnkgb3B0aW1pemVkLCBidXQgSSBkZXNpZ25lZCBpdCBpbg0KaGFsZiBhbiBo b3VyLi4uLg0KPGJyPi4uLi4uSScgc3VyZSBvdXIgY3Jvd2RzIG9mIGVzdGltZWQgaGFja2VycyB3 aWxsIGJlIGFibGUgdG8gZGV2aXNlIHNvbWUNCm11Y2ggbW9yZSBlZmZpY2llbnQgc29sdXRpb25z Li4uLg0KPHA+Q2lhbw0KPGJyPkdpdXNlcHBlDQo8cD5QLlMuDQo8YnI+MXN0IG9wdGltaXphdGlv bjogeW91IHNhaWQgdGhhdCAiVGhpcywgb2YgY291cnNlLCBmb3JjZXMgeW91IHRvIHByb3ZpZGUN CmFwcGxpY2F0aW9uLWxldmVsIGdhdGV3YXlzIGZvciBldmVyeSBVRFAtdXNpbmcgcHJvdG9jb2wg eW91ciBjdXN0b21lcnMNCndhbnQgdG8gdXNlLiINCjxicj5JbnN0ZWFkIG9mIHR1bm5lbGluZyBG aXJld2FsbDEgd2l0aCBIVFRQK1RDUCwgSSBjb3VsZCB0cnkgd2l0aCBvbmUNCm9mIHN1Y2ggVURQ LWJhc2VkIHByb3RvY29scy4uLiAobXVjaCBiZXR0ZXIgISkNCjxicj4mbmJzcDsNCjxicj4mbmJz cDsNCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjxicj4m bmJzcDsNCjxicj4mbmJzcDsNCjxwPkpvbmF0aGFuIExlbm5veCB3cm90ZToNCjxibG9ja3F1b3Rl IFRZUEU9Q0lURT5PbiBUdWUsIE1hcmNoIDI4IDIwMDAsICJHaXVzZXBwZSBSaWNhZ25pIiB3cm90 ZSB0bw0KInNpcEBsaXN0cy5yZXNlYXJjaC5iZWxsLWxhYnMuY29tIiBzYXlpbmc6DQo8cD4+IGR1 cmluZyB0aGVzZSBkYXlzIGluIEFkZWxhaWRlLCBJIGhhdmUgYWxyZWFkeSBoYWQgdGhlIGNoYW5j ZSB0byBkaXNjdXNzDQo8YnI+PiB3aXRoIHNvbWUgd2VsbCBrbm93biBTSVAgZXhwZXJ0cyBhYm91 dCB0aGlzIHRvcGljLCBuZXZlcnRoZWxlc3MgSQ0Kd291bGQNCjxicj4+IGxpa2UgdG8gcG9zZSB0 aGUgc2FtZSBxdWVzdGlvbiB0byB0aGUgbGlzdDogbWF5YmUgc29tZW9uZSBoYXMgc29tZQ0Kb3Ro ZXINCjxicj4+IGlkZWEuDQo8YnI+Pg0KPGJyPj4gTGV0JyBzIGFzc21lIHRoYXQgdGhlIHNjZW5h cm8gaXM6DQo8YnI+Pg0KPGJyPj4mbmJzcDsmbmJzcDsmbmJzcDsgKiB0aGVyZSBhcmUgYSBudW1i ZXIgb2YgInN0YW5kYXJkIiBTSVAgdGVybWluYWxzLA0Kd2hvc2Ugc29mdHdhcmUgaXMNCjxicj4+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vdCBtb2RpZmlhYmxlIGJ5IHRoZSB1c2Vy IChub3IgYW55DQpvdGhlciBhcHBsaWNhdGlvbiBjYW4gYmUNCjxicj4+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGluc3RhbGxlZCkNCjxicj4+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogc3Vj aCBTSVAgc29mdGFyZSBmb3JjZXMgU0lQIHRvIHdvcmsgaW4gcHJveHkNCm1vZGUNCjxicj4+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICogdGhlIHByb3h5IGFjdHVhbGx5IGJpbGxzIHRoZSBjYWxscw0KPGJy Pj4NCjxicj4+IE5vdyBsZXQnIHMgaW50cm9kdWNlIGEgImhhY2tlZCIgdGVybWluYWwsIGFuZCBs ZXRzJyBzIHNheSB0aGF0IHRoZQ0KPGJyPj4gc29mdHdhcmUgb24gc3VjaCB0ZXJtaW5hbCBpcyBj b21wbGV0ZWx5IGZyZWUsIGluIHRoZSBzZW5zZSB0aGF0IHdoYXRldmVyDQo8YnI+PiBpcyBuZWVk ZWQgd2UgY2FuIG1vZGlmeSBpdCBhbmQgaW5zdGFsbCBpdC4NCjxicj4+DQo8YnI+PiBUaGUgcXVl c3Rpb24gaXM6IGlzIGl0IHBvc2libGUgdG8gZGVmaW5lLCB0byBhbnkgZXh0ZW50LCBhIG1lY2hh bmlzbQ0KPGJyPj4gY2FwYWJsZSBvZiBwcmV2ZW50aW5nIHRoZSAiaGFja2VkIiB0ZXJtaW5hbCB0 byBieXBhc3MgdGhlIHByb3h5IGFuZA0KY2FsbA0KPGJyPj4gdGhlICJzdGFuZGFyZCIgZW5kcG9p bnRzIHdpdG91dCBiZWluZyBiaWxsZWQgPw0KPGJyPj4NCjxicj4+IFBsZWFzZSBDQyByZXBsaWVz IHRvIGdyaWNhZ25pQHRpbi5pdCAoaXQgaXMgZWFzaWVyIGZvciBtZSB0byByZWFkDQplbWFpbA0K PGJyPj4gZnJvbSBzdWNoIG1haWxib3ggaGVyZSBpbiBBZGVsYWlkZSkNCjxwPlB1dCB0aGUgdGVy bWluYWxzIGJlaGluZCBhIGZpcmV3YWxsIHdoaWNoIGRvZXNuJ3QgYWxsb3cgcmFuZG9tIFVEUCBw YWNrZXRzDQo8YnI+dGhyb3VnaC4mbmJzcDsgSGF2ZSB0aGUgU0lQIHByb3h5IHRlbGwgdGhlIGZp cmV3YWxsIHRvIG9wZW4gdXAgdGhlDQpwb3J0cyBmb3IgZWFjaA0KPGJyPmNhbGwncyBSVFAgc3Ry ZWFtcyBhZnRlciBpdCBwcm9jZXNzZXMgdGhlIGNvcnJlc3BvbmRpbmcgSU5WSVRFLiZuYnNwOw0K Q2xvc2UgdGhlbQ0KPGJyPndoZW4geW91IHNlZSB0aGUgQllFIG9yIHdoZW4gYSBzZXNzaW9uLXRp bWVyIGV4cGlyZXMgKHlvdSdsbCBuZWVkIHNlc3Npb24NCjxicj50aW1lcnMgZm9yIHRoaXMgdG8g d29yaykuDQo8cD5UaGlzLCBvZiBjb3Vyc2UsIGZvcmNlcyB5b3UgdG8gcHJvdmlkZSBhcHBsaWNh dGlvbi1sZXZlbCBnYXRld2F5cyBmb3INCmV2ZXJ5DQo8YnI+VURQLXVzaW5nIHByb3RvY29sIHlv dXIgY3VzdG9tZXJzIHdhbnQgdG8gdXNlLiZuYnNwOyBJdCBhbHNvIGxlYWRzDQp0byB0aGUNCjxi cj5xdWVzdGlvbiBvZiB3aHkgeW91ciBjdXN0b21lcnMgd29uJ3QganVzdCBkZWNhbXAgdG8gYSBw cm92aWRlciB3aG8NCmdpdmVzDQo8YnI+dGhlbSBwcm9wZXIgZW5kLXRvLWVuZCBJUCBzZXJ2aWNl LCBhbmQgb25seSBiaWxscyBmb3IgdHJ1ZSB2YWx1ZS1hZGRlZA0KPGJyPmZlYXR1cmVzLg0KPHA+ LS0NCjxicj5Kb25hdGhhbiBMZW5ub3gNCjxicj5sZW5ub3hAY3MuY29sdW1iaWEuZWR1PC9ibG9j a3F1b3RlPg0KPC9odG1sPg0KDQo= --0__=6xvNhmaCO2SGZkd8yK3aMO4Tkt29fd4t6KbKPKDA6Ij1EqPESM2vz02e-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 00:06:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29238 for ; Tue, 9 May 2000 00:06:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A5C6D4459A; Mon, 8 May 2000 17:57:59 -0400 (EDT) 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 5A3B244414 for ; Mon, 8 May 2000 17:57:55 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 18:03:22 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 626F344346; Mon, 8 May 2000 15:31:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 31C1D44341 for ; Mon, 8 May 2000 15:31:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C83D752C4; Mon, 8 May 2000 15:31:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C676552B6 for ; Mon, 8 May 2000 15:31:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 15:29:06 EDT 2000 Received: from diablo.cisco.com ([171.68.224.210]) by dusty; Mon May 8 15:29:05 EDT 2000 Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA28921; Mon, 8 May 2000 12:28:16 -0700 (PDT) Message-Id: <4.1.20000508085523.02cc1100@diablo.cisco.com> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 08 May 2000 14:23:31 -0500 To: S_S_Dinesh/India/IBM@au1.ibm.com, Ken Carlberg From: "James M. Polk" Cc: "Rosen, Brian" , sip@lists.research.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_64424256==_.ALT" Subject: [SIP] Re: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --=====================_64424256==_.ALT Content-Type: text/plain; charset="us-ascii" S_S_Dinesh I just got this email (this morning) even though it likely was sent in the past (few months old I think) -- so forgive the following please if this isn't a new position. But in case this was just sent, I have the following response: I'm confused (again), from the line below "...we make protocols that run on the Internet, not the PSTN..." Isn't kinda obvious IP Protocols don't run on a TDM infrastructure where there isn't even IP? SIP is a Protocol that runs on IP, right? So why does this response below want to limit SIP to a Public Internet? Is MCI/WorldCom's Carrier-grade VoIP Network they're rolling out now considered the 'Public Internet'? I kinda don't think so Anything Public doesn't have a fee for services -- which I have to believe MCI/WorldCom plans on charging for use of here. AT&T's Broadband IP Voice network will also have a fee for service -- is that the 'Public Internet'? I kinda don't think so again. Will there be QoS to support SIP on what you consider the 'Public Internet'? That's a good question. Cause if there isn't -- there likely isn't SIP. So.... SIP isn't just for the Public Internet. SIP is for where IP exists that can support a high QoS infrastructure and application that can run on that infrastructure, agreed? If people don't agree with this -- I'd love to hear where they plan on limiting SIP deployments. So.... if SIP is for infrastructures that can support SIP -- why is this only the Internet? S_S_Dinesh, are you only connected to a Internet? Most of us aren't. We're connected to Private Networks that connect to the Public Internet. Why should SIP only start between company networks? From another point of view -- if you, the ones that have only Public Internet Access (via DSL or Cable) and have SIP capability from that location, want to initiate a SIP session between yourself and someone that isn't in a Public Internet connected location, that session doesn't work does it? Based on what you've decreed, it cannot. What if you were in fact initiating a session to someone's IP Phone that ran SIP in some internal network that was connected to that Public Internet you were? Could that session exist? If it can, my I-D can too. If you're objecting to my extension to the Priority Header-Field, were you also opposed to what is there now? There are 4 levels -- I'm merely suggesting a 5th. Jonathan admitted at Adelaide that ".. no one uses this now.." Great. Except when he asked the audience (of substantial size) what they felt about it -- it appears nearly unanimous that this was worth pursuing. I agree I need to rewrite the I-D towards what only involves SIP (in which Preemption is merely referenced and not mandated within it). But if there is to be Priority within a SIP network, semantics for how and examples of where, should be written and accepted by this WG. BTW -- if will be actually changed within the SIP work is the addition of a single value to an existing Header-Field, why are you so opposed to this work? If it isn't used by you -- so what? If it is used, and in this case it is mandatory for certain installations of very large size -- what harm did it cause you? It should be little if any: an unused Header-Field with an additional value. What parts of this don't make sense to people? At 02:10 PM 5/8/2000 +0530, S_S_Dinesh/India/IBM@au1.ibm.com wrote: > > > > >Ken Carlberg wrote: >> >> > On your final thread, it should certainly be possible to define >> > an extension to SIP that is not useful in the PSTN; extensions >> > that are useful only within an enterprise for example should >> > be acceptable, or in the home, as well as something like MLPP >> > which is useful within a government communications system. >> >> Agreed with respect to something that may or may not be "useful". But >the >> kicker that I'm curious about is whether the proposed specification is >> illegal (not allowed) when applied to the general public. > >Here at IETF, we make protocols that run on the Internet, not the PSTN. >As there are no regulations regarding this kind of thing on the >Internet, it is not an issue for us. > >-Jonathan R. > > >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (732) 741-4778 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > > > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_64424256==_.ALT Content-Type: text/html; charset="us-ascii"
S_S_Dinesh

I just got this email (this morning) even though it likely was sent in the past (few months old I think) -- so forgive the following please if this isn't a new position. But in case this was just sent, I have the following response:

I'm confused (again), from the line below "...we make protocols that run on the Internet, not the PSTN..." Isn't kinda obvious IP Protocols don't run on a TDM infrastructure where there isn't even IP?

SIP is a Protocol that runs on IP, right?

So why does this response below want to limit SIP to a Public Internet? Is MCI/WorldCom's Carrier-grade VoIP Network they're rolling out now considered the 'Public Internet'? I kinda don't think so Anything Public doesn't have a fee for services -- which I have to believe MCI/WorldCom plans on charging for use of here.

AT&T's Broadband IP Voice network will also have a fee for service -- is that the 'Public Internet'? I kinda don't think so again.

Will there be QoS to support SIP on what you consider the 'Public Internet'? That's a good question. Cause if there isn't -- there likely isn't SIP.

So.... SIP isn't just for the Public Internet. SIP is for where IP exists that can support a high QoS infrastructure and application that can run on that infrastructure, agreed? If people don't agree with this -- I'd love to hear where they plan on limiting SIP deployments.

So.... if SIP is for infrastructures that can support SIP -- why is this only the Internet? S_S_Dinesh, are you only connected to a Internet? Most of us aren't. We're connected to Private Networks that connect to the Public Internet. Why should SIP only start between company networks?

From another point of view -- if you, the ones that have only Public Internet Access (via DSL or Cable) and have SIP capability from that location, want to initiate a SIP session between yourself and someone that isn't in a Public Internet connected location, that session doesn't work does it? Based on what you've decreed, it cannot.

What if you were in fact initiating a session to someone's IP Phone that ran SIP in some internal network that was connected to that Public Internet you were? Could that session exist? If it can, my I-D can too.

If you're objecting to my extension to the Priority Header-Field, were you also opposed to what is there now? There are 4 levels -- I'm merely suggesting a 5th. Jonathan admitted at Adelaide that ".. no one uses this now.." Great. Except when he asked the audience (of substantial size) what they felt about it -- it appears nearly unanimous that this was worth pursuing.

I agree I need to rewrite the I-D towards what only involves SIP (in which Preemption is merely referenced and not mandated within it). But if there is to be Priority within a SIP network, semantics for how and examples of where, should be written and accepted by this WG.

BTW -- if will be actually changed within the SIP work is the addition of a single value to an existing Header-Field, why are you so opposed to this work? If it isn't used by you -- so what? If it is used, and in this case it is mandatory for certain installations of very large size -- what harm did it cause you? It should be little if any: an unused Header-Field with an additional value.

What parts of this don't make sense to people?


At 02:10 PM 5/8/2000 +0530, S_S_Dinesh/India/IBM@au1.ibm.com wrote:
>
>
>
>
>Ken Carlberg wrote:
>>
>> > On your final thread, it should certainly be possible to define
>> > an extension to SIP that is not useful in the PSTN; extensions
>> > that are useful only within an enterprise for example should
>> > be acceptable, or in the home, as well as something like MLPP
>> > which is useful within a government communications system.
>>
>> Agreed with respect to something that may or may not be "useful".  But
>the
>> kicker that I'm curious about is whether the proposed specification is
>> illegal (not allowed) when applied to the general public.
>
>Here at IETF, we make protocols that run on the Internet, not the PSTN.
>As there are no regulations regarding this kind of thing on the
>Internet, it is not an issue for us.
>
>-Jonathan R.
>
>
>--
>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>
>
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_64424256==_.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 May 9 00:08:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29250 for ; Tue, 9 May 2000 00:08:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 122ED444A5; Mon, 8 May 2000 16:40:54 -0400 (EDT) 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 C9FE3444B5 for ; Mon, 8 May 2000 16:39:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:44:27 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 90D0C44396; Mon, 8 May 2000 14:21:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BDC424439F for ; Mon, 8 May 2000 14:21:21 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1998952AB; Mon, 8 May 2000 14:21:21 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id E993952D0 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18499 for ; Mon, 8 May 2000 06:09:34 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:30 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:58:29 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA207060; Mon, 8 May 2000 19:53:21 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA14702; Mon, 8 May 2000 19:58:20 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036C539 ; Mon, 8 May 2000 19:58:14 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: "Gazal, Elly" Cc: "'sip@lists.research.bell-labs.com'" Message-ID: Date: Mon, 8 May 2000 14:10:06 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Message Waiting Indication Supplementary Service Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Getting or checking the status of a voice mailbox is orthogonal to SIP's purpose (establishing sessions). You could use a separate protocol, or you could use either the SIP INFO or SUBSCRIBE/NOTIFY methods to provide supplemental information to the phone/endpoint. You could use an XML, plain text, or other body type to convey this information, or an Event: header. thanks, -rohan At 12:12 AM 3/20/00 , Gazal, Elly wrote: >Can any one suggest how does Message Waiting Indication Supplementary >Service is achieved by SIP? > >Regards, > >Elly. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 00:09:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29261 for ; Tue, 9 May 2000 00:09:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 36D78445AA; Mon, 8 May 2000 23:38:22 -0400 (EDT) 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 7AC0944560 for ; Mon, 8 May 2000 23:37:53 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 23:42:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 44D7D44344; Mon, 8 May 2000 23:29:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1E61044341 for ; Mon, 8 May 2000 23:29:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7410352C4; Mon, 8 May 2000 23:29:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 74ED452B6 for ; Mon, 8 May 2000 23:29:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 23:27:35 EDT 2000 Received: from exchangesvr.nuera.com ([204.216.240.124]) by dusty; Mon May 8 23:27:35 EDT 2000 Received: by EXCHANGESVR with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 20:30:02 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" Cc: "'sip@lists.research.bell-labs.com'" Subject: RE: [SIP] Content-Language header Date: Mon, 8 May 2000 20:29:55 -0700 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hear hear !! -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, May 09, 2000 3:20 AM To: ozsip@oz.com Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Content-Language header What you are describing is actually something different still. Accept-Language describes the language that may be used for the content in a response. This has nothing to do with the language an operator you might be connected to is able to speak; for that, the caller preferences extension is targeted (in fact, it has preferences for languages spoken). This is also different from Content-Language, which describes the language of the html or text in a SIP response. As Henning has pointed out, the only real use for this is some kind of automated translation systems. I know its optional and not hard, but I would rather not add more stuff to an ever-more-complex protocol unless there is a very well defined need. Since there is realistically no useful application right now of Content-Language, I'd rather not add it. -Jonathan R. ozsip@oz.com wrote: > > > Realistically, what are the applications for Content-Language? What > > would a client do differently on receiving a Spanish version vs. > > English? I see the value in Accept-Language, so that I get the right > > thing back in the first place, but Content-Language? > > Perhaps if you would send a SIP invitation with "Content-Language: Spanish" > to sip:support@somewhere.com, you would prefer the proxy at somewhere.com > to route your call to a support representative who spoke spanish. > > -David H. Brandt > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 9 00:10:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29287 for ; Tue, 9 May 2000 00:10:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 91B4C444E6; Mon, 8 May 2000 16:52:04 -0400 (EDT) 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 51F3C444D9 for ; Mon, 8 May 2000 16:51:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:57:35 EDT 2000 Received: by lists.bell-labs.com (Postfix) id EABEF443A1; Mon, 8 May 2000 14:21:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id BB3AB443A0 for ; Mon, 8 May 2000 14:21:24 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 84C7252AB; Mon, 8 May 2000 14:21:23 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 760BC52C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18443 for ; Mon, 8 May 2000 06:07:51 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:10 EDT 2000 Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by dusty; Mon May 8 05:58:09 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA148694; Mon, 8 May 2000 19:53:02 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA51328; Mon, 8 May 2000 19:58:01 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036BF9B ; Mon, 8 May 2000 19:57:59 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Sunitha Kumar Cc: SIPbell-labs Message-ID: Date: Mon, 8 May 2000 14:10:04 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: BYE and record route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com It certainly should, and not only for BYE requests. This is discussed in http://www.cs.columbia.edu/~hgs/sip/notes.html (see the note on Record-Route towards the end of the document) and in http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf (section 6.3.33). --- Igor Slepchin Sunitha Kumar wrote: > > It is given that the record route in 200 OK is copied into the Route > headers for subsequent requests from the caller. My question was, if > we needed to make the BYE from the *callee* traverse the same set of > proxies, then should this be rememberd from the INVITE request > obtained from the caller, or does the via field help in that. > > Thanks! > > -- > Sunitha Kumar > Software Engineer > Vovida Networks > (408) 957 - 6374 > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 00:13:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29311 for ; Tue, 9 May 2000 00:13:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EBE344563; Mon, 8 May 2000 17:41:03 -0400 (EDT) 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 34BA844565 for ; Mon, 8 May 2000 17:31:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:37:04 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 73136443C0; Mon, 8 May 2000 14:21:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 4F1D1443AF for ; Mon, 8 May 2000 14:21:47 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3B58052C4; Mon, 8 May 2000 14:21:46 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 72F2952B6 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18527 for ; Mon, 8 May 2000 06:10:50 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:59:03 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:59:01 EDT 2000 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA164300; Mon, 8 May 2000 19:53:30 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA20972; Mon, 8 May 2000 19:58:47 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036D1E3 ; Mon, 8 May 2000 19:58:46 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com, Robert.Sparks@wcom.com Message-ID: Date: Mon, 8 May 2000 14:10:09 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Comments on transfer draft (sparks-sip-cc-transfer-00) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Henning Schulzrinne wrote: > > A few low-level comments: > > - I'm not sure "TRANSFER" is the right verb here, since transfer implies > moving something from one place to another. All TRANSFER does is > effectively ask the recipient to send another INVITE. It would be nice > if the same action could be used (say) for mesh conferences. It would be nice, and indeed this is the motivation which led us to use Also for both in the original call control draft. Problem is, a full mesh conference requires much more than just "send an INVITE to so-and-so". It requires a fair amount of synchronization and additional semantics, beyond what is needed for transfer. However, I agree that the mechanism might have other uses besides transfer, so something more functional would be nice. I also agree that we should figure out the primitive functions we need to accomplish the call control capabilities, and then specify extensions for the primitives rather than the services. The services themselves can then be described through informational documents that reference the extensions. I think the idea proposed in the framework, of basically breaking call control into separate pieces, is probably a good idea. > - Using TRANSFER instead of INVITE with Also does have one major > disadvantage, since the originator of the request will retransmit with > T2 (4 seconds). An excellent point. Another advantage of BYE/Also over a new method is that it saves two messages (separate TRANSFER/response and BYE/response) when implementing your basic blind transfer. However, I think a new method is better, in the end. It becomes increasingly complex to figure out how to handle an INVITE or BYE request if it can be filled with tons of headers, each doing a separate thing. Also, by overloading BYE, the interpretation of the response becomes harder. If the response to a BYE/Also was 400, was this because the transfer failed, or because the BYE itself was bad? Using a specific method makes it clear what the response means. Also, using a new method means that the same mechanism can support unattended transfers, blind transfers, and a bunch of others. So, if we go by the philosophy in the "Guidelines for Authors of SIP Extensions" draft, generality and flexibility wins over efficiency, which speaks for a new method. > > - According to the rules for feature names, IETF-based extensions are > single words, to avoid any possible confusion with proprietary > extensions having inverted domain names. Thus, it should probably just > be Requires: transfer rather than cc.transfer. (On the other hand, it's > not clear this is needed at all - we don't need Require for new methods, > since they already have a mechanism to say "sorry, je ne comprend pas"). Require is definitely not needed. This is an advantage to new methods as opposed to new headers in an existing method. It would be really nice, however, to know ahead of time whether all parties supported transfer (and any other mechanisms to be defined). The Supported extension draft defines a way in which the UAC would indicate to the UAS that it knows the new mechanism, but that draft does not mandate that a UAS return a Supported header in the response to any method (only OPTIONS). We can add this, and say that if a UAS receives a request (with any method) with a Supported header, it should place a Supported header in the response and list those features it knows. This would allow a caller to know whether the called party supports transfer before trying it. Thoughts? I noted the following in the transfer draft: > Explicit non-Requirements > > 1. There is no requirement for the Transfer Target to be notified > that he is receiving an INVITE as the result of a TRANSFER request > (see comment 2). Why? I really liked the idea of knowing that this call was the result of a transfer, and knowing who the transferor was. A UA can always ignore this information, and then get the basic service you have today. The document says TRANSFER can't have a body. Why not? I can think of some cool uses for this down the road. Why rule it out? The draft says: > UA receiving a well-formed TRANSFER request SHOULD request approval > from the user to proceed. In the absence of that request, or upon > receiving approval from the user, the UA MUST submit an INVITE to > the resource identified by the Transfer-To: header using the Call-ID > from the TRANSFER request. This thing about the Call-ID being copied from the TRANSFER seemed odd. Why is that? If you wanted to accomplish this, it seems better to have the URL in the Transfer-To header contain the Call-ID as a URL parameter. In other words, why not do: Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 9 00:19:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29348 for ; Tue, 9 May 2000 00:19:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2062444E3; Mon, 8 May 2000 17:17:25 -0400 (EDT) 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 DCD9844510 for ; Mon, 8 May 2000 17:05:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 17:10:44 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3986D443AC; Mon, 8 May 2000 14:21:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 13A7D443A8 for ; Mon, 8 May 2000 14:21:32 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1146852B6; Mon, 8 May 2000 14:21:31 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 0C98752AB for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18300 for ; Mon, 8 May 2000 06:01:33 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:06 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:58:05 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA119020; Mon, 8 May 2000 19:52:38 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA36194; Mon, 8 May 2000 19:57:54 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036B5DD ; Mon, 8 May 2000 19:57:35 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Linden deCarmo , sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:02 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] RE: SIP & RTSP interworking? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Here's what I would suggest: Build a SIP UAS that understands the RTSP end and contains stream management logic. This UAS either reinvites to establish the link to RTSP streams, or copies the RTP from each stream back into the media path for the remote UA. I know of some people(s) who are already using each approach to build a voice mail system that can use a standard RTSP server as a media store. Makes unified messaging with URL passing MUCH easier. -- dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Linden > deCarmo > Sent: Tuesday, March 14, 2000 7:27 AM > To: 'sip@lists.research.bell-labs.com' > Subject: SIP & RTSP interworking? > > > What would be the proper (or suggested) procedure to tie a SIP > session to an > RTSP session? > > What I'd like to do is setup a session with SIP (via an INVITE), then > control streaming aspects via RTSP (i.e. play, pause, stop etc.). > However, > its not clear to me how I tie the RTSP session id to the previously > established SIP session. > > Thanks. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 00:20:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29363 for ; Tue, 9 May 2000 00:20:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57CEE444D9; Mon, 8 May 2000 16:52:23 -0400 (EDT) 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 98E5A444DE for ; Mon, 8 May 2000 16:51:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 8 16:57:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 81187443A0; Mon, 8 May 2000 14:21:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 4C8A0443A4 for ; Mon, 8 May 2000 14:21:26 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8113D52AB; Mon, 8 May 2000 14:21:25 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by lists.research.bell-labs.com (Postfix) with ESMTP id 4D2B352C8 for ; Mon, 8 May 2000 14:19:26 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id GAA18559 for ; Mon, 8 May 2000 06:11:34 -0400 (EDT) From: S_S_Dinesh/India/IBM@au1.ibm.com Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 8 05:58:42 EDT 2000 Received: from ausmtp01.au.ibm.com ([202.135.136.97]) by dusty; Mon May 8 05:58:40 EDT 2000 Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA226260; Mon, 8 May 2000 19:53:14 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id TAA53150; Mon, 8 May 2000 19:58:30 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568D9.0036CA8D ; Mon, 8 May 2000 19:58:27 +1000 X-Lotus-FromDomain: IBMAU@IBMIN@IBMAU To: Ravandhu Hariram Cc: sip@lists.research.bell-labs.com Message-ID: Date: Mon, 8 May 2000 14:10:06 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Re: Update of 'Contact' address Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Ravandhu Hariram wrote: > > After a call is fully connected between two user agents, if one user agent sends > a new INVITE request with a different 'Contact' address, should the receiving > user agent update its 'Route' header with this modified 'Contact' address? I think so. There are a few applications of this, including mobility and a few call services. Note, however, that updating of the Route with new Record-Route headers is different. RFC2543 forbids (I think) insertion of Record-Route headers when a Route is already there. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 9 06:37:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14016 for ; Tue, 9 May 2000 06:37:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C79A344341; Tue, 9 May 2000 06:30:58 -0400 (EDT) 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 3985744336 for ; Tue, 9 May 2000 06:30:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14006; Tue, 9 May 2000 06:37:05 -0400 (EDT) Message-Id: <200005091037.GAA14006@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 Date: Tue, 09 May 2000 06:37:05 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --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, A. Vemuri, L. Ong, M. Zonoun, M. Watson Filename : draft-ietf-sip-isup-mime-01.txt Pages : 6 Date : 08-May-00 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-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-isup-mime-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-isup-mime-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: <20000508143822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-mime-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-mime-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000508143822.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 07:00:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14333 for ; Tue, 9 May 2000 07:00:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 870F144359; Tue, 9 May 2000 06:53:53 -0400 (EDT) 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 01C7D44336 for ; Tue, 9 May 2000 06:53:50 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 9 06:58:24 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5C60F44344; Tue, 9 May 2000 06:45:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 359F744341 for ; Tue, 9 May 2000 06:45:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 91A6452C4; Tue, 9 May 2000 06:45:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B865852AB for ; Tue, 9 May 2000 06:45:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 9 06:44:25 EDT 2000 Received: from web4605.mail.yahoo.com ([216.115.105.160]) by dusty; Tue May 9 06:44:24 EDT 2000 Message-ID: <20000509102141.23509.qmail@web4605.mail.yahoo.com> Received: from [136.182.2.222] by web4605.mail.yahoo.com; Tue, 09 May 2000 03:21:41 PDT Date: Tue, 9 May 2000 03:21:41 -0700 (PDT) From: Vivek Rao To: sip@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Sip Grammer: Multiple entries Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi The grammer for contact specified in RFC2543bis is as follows Contact = ("Contact"|"m")":" ("*"|(1#((name_addr|addr_spec) {*(";"contact-params)]))) name_addr = [display-name]"<"addr_spec">" addr_spec = SIP-URL|URI In the example below Contact:;action=proxy,gaya Since the grammar for URI field accepts a ';' , '=' & ',' , ";action=proxy,gaya" will be identified as a URI. Hence its required to scan through this to retrieve the Contact-Param. All this can be avoided if we allow a minimum of one space on either side of comma. Similar situation occurs for Via, Route & Record-Route. A similar situation occurs if a colon(:) is immediately followed by a display name as in From or To fields (e.g. From:Jerry). Please clarify on this. Thanks Vivek __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.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 Tue May 9 10:34:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21270 for ; Tue, 9 May 2000 10:34:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B05444346; Tue, 9 May 2000 10:27:53 -0400 (EDT) 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 90FD144336 for ; Tue, 9 May 2000 10:27:50 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 9 10:32:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A3BCB44345; Tue, 9 May 2000 10:19:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7B0E244341 for ; Tue, 9 May 2000 10:19:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 44D6952C4; Tue, 9 May 2000 10:19:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4527B52AB for ; Tue, 9 May 2000 10:19:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 9 10:17:42 EDT 2000 Received: from smtprch1.nortel.com ([192.135.215.14]) by dusty; Tue May 9 10:17:41 EDT 2000 Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Tue, 9 May 2000 09:14:07 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQHRHPCL; Tue, 9 May 2000 10:13:58 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K365NY1F; Tue, 9 May 2000 10:14:01 -0400 Message-ID: <39181DF5.1D7B2CA0@americasm01.nt.com> Date: Tue, 09 May 2000 10:17:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Vivek Rao Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Sip Grammer: Multiple entries References: <20000509102141.23509.qmail@web4605.mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------AAAEF9D3DC3BF61F60CA2D22" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------AAAEF9D3DC3BF61F60CA2D22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vivek Rao wrote: > Hi > The grammer for contact specified in RFC2543bis is > as follows > > Contact = ("Contact"|"m")":" > ("*"|(1#((name_addr|addr_spec) > {*(";"contact-params)]))) > name_addr = [display-name]"<"addr_spec">" > addr_spec = SIP-URL|URI > > In the example below > Contact:;action=proxy,gaya > > Since the grammar for URI field accepts a ';' , '=' & > ',' , ";action=proxy,gaya" will be identified as a > URI. Hence its required to scan through this to > retrieve the Contact-Param. All this can be avoided if > we allow a minimum of one space on either side of > comma. My interpretation is the URI (or in this case SIP-URL) completes when the ">" is encountered so the "action=proxy" is parsed as a legal contact-param. So I don't understand the problem. > > Similar situation occurs for Via, Route & > Record-Route. > > A similar situation occurs if a colon(:) is > immediately followed by a display name as in From or > To fields (e.g. From:Jerry). > This one's a bit more problematical because "Jerry" is a valid URI (a relativeURI), but then again almost anything is. It can't be a display name because it's not followed by a "<" addr-spec ">". However, I don't think inserting a space helps, does it? (Inserting white space is always allowed in headers, but only mandatory when header elements need to be separated, i.e., between two tokens.) > > Please clarify on this. > Thanks > Vivek > > __________________________________________________ > Do You Yahoo!? > Send instant messages & get email alerts with Yahoo! Messenger. > http://im.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip Rick Workman Nortel Networks Ottawa --------------AAAEF9D3DC3BF61F60CA2D22 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Vivek Rao wrote:

Hi
   The grammer for contact specified in RFC2543bis is
as follows

Contact   = ("Contact"|"m")":"
                 ("*"|(1#((name_addr|addr_spec)
{*(";"contact-params)])))
name_addr = [display-name]"<"addr_spec">"
addr_spec  = SIP-URL|URI

In the example below
Contact:<sip:tree@yahoo.com>;action=proxy,gaya<sip:someone@anwhere.com>

Since the grammar for URI field accepts a ';' , '=' &
',' , ";action=proxy,gaya" will be identified as a
URI. Hence its required to scan through this to
retrieve the Contact-Param. All this can be avoided if
we allow a minimum of one space on either side of
comma.

My interpretation is the URI (or in this case SIP-URL) completes when the ">" is encountered so the "action=proxy" is parsed as a legal contact-param. So I don't understand the problem.
 
Similar situation occurs for Via, Route &
Record-Route.

A similar situation occurs if a colon(:) is
immediately followed by a display name as in From or
To fields (e.g. From:Jerry).
 

This one's a bit more problematical because "Jerry" is a valid URI (a relativeURI), but then again almost anything is. It can't be a display name because it's not followed by a "<" addr-spec ">". However, I don't think inserting a space helps, does it? (Inserting white space is always allowed in headers, but only mandatory when header elements need to be separated, i.e., between two tokens.)
 
Please clarify on this.
Thanks
Vivek

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

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

Rick Workman
Nortel Networks
Ottawa --------------AAAEF9D3DC3BF61F60CA2D22-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 11:28:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22608 for ; Tue, 9 May 2000 11:28:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81F4244352; Tue, 9 May 2000 11:21:53 -0400 (EDT) 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 EF5C444336 for ; Tue, 9 May 2000 11:21:50 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 9 11:26:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0A31344344; Tue, 9 May 2000 11:13:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id CC56244341 for ; Tue, 9 May 2000 11:13:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id BBA2352C4; Tue, 9 May 2000 11:13:06 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E266852AB for ; Tue, 9 May 2000 11:13:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue May 9 11:12:25 EDT 2000 Received: from motgate.mot.com ([129.188.136.100]) by dusty; Tue May 9 11:12:24 EDT 2000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA27512 for ; Tue, 9 May 2000 08:12:22 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA02510 for ; Tue, 9 May 2000 08:12:21 -0700 (MST)] Received: from shruthi.miel.mot.com (shruthi.miel.mot.com [217.1.127.76]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id UAA28674 for ; Tue, 9 May 2000 20:46:49 +0530 (IST) Received: from pc127162 (pc127162.miel.mot.com [217.1.127.162]) by shruthi.miel.mot.com (8.9.1/8.9.1) with SMTP id UAA29622 for ; Tue, 9 May 2000 20:41:54 +0530 (IST) Reply-To: From: "Albee Vimal" To: Date: Tue, 9 May 2000 20:43:48 +0530 Message-ID: <002201bfb9c9$2dd67e20$a27f01d9@pc127162.miel.mot.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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Subject: [SIP] Some clarifications on action field in Contact Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi We have some doubts on the action parameter that is associated with a Contact field. 1.We would like to know what it means when we register with action= redirect or proxy. Does it mean that if a registration is made with action=redirect, then on receiving an INVITE destined to the registered location, network server sends a 3XX response to the UAC with all the new contact locations in the Contact field. The UAC then sends INVITE to all the new locations mentioned in the Contact field. 2. This is valid only if an UAC can send redirected INVITE to multiple locations. UAC while forwarding a redirected INVITE replaces the Request-URI with the received Contact addresses. If one of the redirected endpoints responds with a 2XX response, the UAC will be able to forward an ACK to the Contact field coresponding to it (since the RFC's mandates that a 2XX response to INVITE contain a Contact field (6.13, Pg. 39)). But is'nt it mandatory for an endpoint sending a 6XX response to insert a Contact field as well. 3. This is related to 2. On receiving a >3XX response from one of the endpoints how will the UAC identify the location to which it has to send an ACK. i.e how would this response be matched with a request transaction, since the request was sent to multiple destinations. 4. In "16.6 Redirects" example in the RFC we find two Cseq fields in the 302 response. We would like to know whether it is allowed to have multiple CSeq fields. Please clarify on these Thanks Albee Vimal _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 11:58:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23333 for ; Tue, 9 May 2000 11:58:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1C4A4436F; Tue, 9 May 2000 11:51:55 -0400 (EDT) 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 1F83744336 for ; Tue, 9 May 2000 11:51:51 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 9 11:56:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 15FD144344; Tue, 9 May 2000 11:43:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id D868F44341 for ; Tue, 9 May 2000 11:43:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id BE4B652C4; Tue, 9 May 2000 11:43:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D4CEA52B6 for ; Tue, 9 May 2000 11:43:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 9 11:42:18 EDT 2000 Received: from motgate.mot.com ([129.188.136.100]) by dusty; Tue May 9 11:42:17 EDT 2000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA29062; Tue, 9 May 2000 08:42:16 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA11535; Tue, 9 May 2000 08:42:14 -0700 (MST)] Received: from shruthi.miel.mot.com (shruthi.miel.mot.com [217.1.127.76]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id VAA01017; Tue, 9 May 2000 21:16:42 +0530 (IST) Received: from pc127162 (pc127162.miel.mot.com [217.1.127.162]) by shruthi.miel.mot.com (8.9.1/8.9.1) with SMTP id VAA00162; Tue, 9 May 2000 21:11:48 +0530 (IST) Reply-To: From: "Albee Vimal" To: "'Rick Workman'" Cc: Subject: RE: [SIP] Sip Grammar: Multiple entries Date: Tue, 9 May 2000 21:13:42 +0530 Message-ID: <002301bfb9cd$5abec830$a27f01d9@pc127162.miel.mot.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01BFB9FB.74770430" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <39181DF5.1D7B2CA0@americasm01.nt.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0024_01BFB9FB.74770430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks for responding to our doubts. Since the URI/addr-spec grammar accepts alpha-numeric, ";" , "," , "=" etc. We find that during the lexical analysis the rule/token that matches the maximum number of input is returned hence ";action=proxy,gaya" is returned as a single URI token, instead of being returned as contact-param ,a comma token (comma token refers to ',') and display-name token (refers the 'gaya'). Earlier we were trying to convey that if a space is introduced we can avoid this situation and make token retrieval more easy. Sorry, for giving an incomplete example it should have been From:Jerry Here since there is no space between the ':' and 'Jerry', even though we specify rule to return From as a separate token and ':' as another. The lexical analyzer goes for the maximum pattern match and returns "From:Jerry" as the URI/addr-spec token. The grammar works fine in identifying as URI/addr-spec token. Had there been a space between ':' and display-name "From:Jerry" would not be returned as a addr-spec token. Yes, this can be overcome by having some special condition checks and doing rescan. What we thought was this could be avoided if a space is mandated in both the cases. Thanks Albee Vimal -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rick Workman Sent: Tuesday, May 09, 2000 7:47 PM To: Vivek Rao Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Sip Grammer: Multiple entries Vivek Rao wrote: Hi The grammer for contact specified in RFC2543bis is as follows Contact = ("Contact"|"m")":" ("*"|(1#((name_addr|addr_spec) {*(";"contact-params)]))) name_addr = [display-name]"<"addr_spec">" addr_spec = SIP-URL|URI In the example below Contact:;action=proxy,gaya Since the grammar for URI field accepts a ';' , '=' & ',' , ";action=proxy,gaya" will be identified as a URI. Hence its required to scan through this to retrieve the Contact-Param. All this can be avoided if we allow a minimum of one space on either side of comma. My interpretation is the URI (or in this case SIP-URL) completes when the ">" is encountered so the "action=proxy" is parsed as a legal contact-param. So I don't understand the problem. Similar situation occurs for Via, Route & Record-Route. A similar situation occurs if a colon(:) is immediately followed by a display name as in From or To fields (e.g. From:Jerry). This one's a bit more problematical because "Jerry" is a valid URI (a relativeURI), but then again almost anything is. It can't be a display name because it's not followed by a "<" addr-spec ">". However, I don't think inserting a space helps, does it? (Inserting white space is always allowed in headers, but only mandatory when header elements need to be separated, i.e., between two tokens.) Please clarify on this. Thanks Vivek __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip Rick Workman Nortel Networks Ottawa ------=_NextPart_000_0024_01BFB9FB.74770430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks=20 for responding to our doubts.
 Since=20 the URI/addr-spec grammar accepts alpha-numeric, ";" ,  "," , "=3D" = etc. We=20 find that during the lexical analysis the rule/token that matches = the=20 maximum number of input is returned  hence = ";action=3Dproxy,gaya" is=20 returned  as a single URI token, instead of being returned as = contact-param=20 ,a comma token (comma token refers to ',') and display-name token = (refers the=20 'gaya'). Earlier we were trying to convey that if a space is = introduced we=20 can avoid this situation and make token retrieval more=20 easy.
 
Sorry,=20 for giving an incomplete example it should have been =
       &nbs= p;         =20 From:Jerry<sip:any@doubt>
Here=20 since there is no space between the ':' and 'Jerry', even though we = specify=20 rule to return From as a separate token and ':' as another. The lexical = analyzer=20 goes for the maximum pattern match and returns "From:Jerry" as the = URI/addr-spec=20 token.  The grammar works fine in identifying <sip:any@doubt> = as=20 URI/addr-spec token. Had there been a space between ':' and = display-name=20 "From:Jerry" would not be returned as a addr-spec token. =
Yes,=20 this can be overcome by having some special condition checks and doing = rescan.=20 What we thought was this could be avoided if a space is mandated in both = the=20 cases. 
Thanks
Albee=20 Vimal
 -----Original = Message-----
From:=20 sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On Behalf=20 Of Rick Workman
Sent: Tuesday, May 09, 2000 7:47 = PM
To:=20 Vivek Rao
Cc: = sip@lists.research.bell-labs.com
Subject: Re:=20 [SIP] Sip Grammer: Multiple entries

 =20

Vivek Rao wrote:=20

Hi
   The grammer = for=20 contact specified in RFC2543bis is
as = follows=20

Contact   =3D ("Contact"|"m")":"=20 =
           = ;     =20 ("*"|(1#((name_addr|addr_spec) =
{*(";"contact-params)])))=20
name_addr =3D [display-name]"<"addr_spec">"=20
addr_spec  =3D SIP-URL|URI=20

In the example below=20 =
Contact:<sip:tree@yahoo.com>;action=3Dproxy,gaya<sip:som= eone@anwhere.com>=20

Since the grammar for URI field accepts a ';' , '=3D' = &=20
',' , ";action=3Dproxy,gaya" will be identified as a =
URI.=20 Hence its required to scan through this to
retrieve the = Contact-Param. All this can be avoided if
we allow a = minimum of=20 one space on either side of =
comma.

My=20 interpretation is the URI (or in this case SIP-URL) completes when the = ">"=20 is encountered so the "action=3Dproxy" is parsed as a legal = contact-param. So I=20 don't understand the problem.=20
 
Similar situation = occurs for=20 Via, Route &
Record-Route.=20

A similar situation occurs if a colon(:) is =
immediately=20 followed by a display name as in From or
To fields = (e.g.=20 From:Jerry).
 

This one's = a bit=20 more problematical because "Jerry" is a valid URI (a relativeURI), but = then=20 again almost anything is. It can't be a display name because it's not = followed=20 by a "<" addr-spec ">". However, I don't think inserting a space = helps,=20 does it? (Inserting white space is always allowed in headers, but only = mandatory when header elements need to be separated, i.e., between two = tokens.)=20
 
Please clarify on = this.=20
Thanks
Vivek=20

__________________________________________________ =
Do=20 You Yahoo!?
Send instant messages & get email = alerts with=20 Yahoo! Messenger.
http://im.yahoo.com/ =

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

Rick=20 Workman
Nortel Networks
Ottawa=20
------=_NextPart_000_0024_01BFB9FB.74770430-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 12:18:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23884 for ; Tue, 9 May 2000 12:18:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5CB954435A; Tue, 9 May 2000 12:11:52 -0400 (EDT) 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 C97314434A for ; Tue, 9 May 2000 12:11:49 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 9 12:16:29 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7015944344; Tue, 9 May 2000 12:03:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3D32344341 for ; Tue, 9 May 2000 12:03:20 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 324A552C4; Tue, 9 May 2000 12:03:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5908052B6 for ; Tue, 9 May 2000 12:03:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 9 12:01:19 EDT 2000 Received: from ertpg14e1.nortelnetworks.com ([47.234.0.35]) by dusty; Tue May 9 12:01:18 EDT 2000 Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Tue, 9 May 2000 11:22:18 -0400 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KTCJN4RS; Tue, 9 May 2000 11:22:17 -0400 Received: from long-pc.corpwest.baynetworks.com. (long-pc.corpwest.baynetworks.com [134.177.35.52]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJLBYJ6M; Tue, 9 May 2000 08:22:15 -0700 Message-Id: <3.0.1.32.20000509082131.0100b23c@zsc4c006.corpwest.baynetworks.com> X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 09 May 2000 08:21:31 -0700 To: sip@lists.research.bell-labs.com X-Sybari-Space: 00000000 00000000 00000000 From: "Lyndon Ong" In-Reply-To: <3912469A.2D1FE236@dynamicsoft.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [SIP] SIP ISUP MIME type update Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Folks, I've sent in updated version of the SIP ISUP MIME type draft (draft-ietf-sip-isup-mime-01.txt). Changes as a result of discussion on the sip-t list include the following: -- ISUP "version" parameter is now mandatory, "base" is added as an optional parameter -- some modified wording is given in the security section reflecting concerns about security of information in the encapsulated messages A couple of corrections were made based on comments received: -- some corrections were made to the list of different ISUP base versions provided in the draft -- some corrections were made to the ISUP example in section 4.1, esp. a note that the ISUP message is provided starting with the Message Type Code (without routing label or CIC). Cheers, L. Ong _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 14:26:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27190 for ; Tue, 9 May 2000 14:26:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01D924433B; Tue, 9 May 2000 14:19:50 -0400 (EDT) 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 8449C44336 for ; Tue, 9 May 2000 14:19:48 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 9 14:24:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D067244344; Tue, 9 May 2000 14:11:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9DC7344341 for ; Tue, 9 May 2000 14:11:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E9C4A52C4; Tue, 9 May 2000 14:11:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 763DA52B6 for ; Tue, 9 May 2000 14:11:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 9 14:09:23 EDT 2000 Received: from ertpg14e1.nortelnetworks.com ([47.234.0.35]) by dusty; Tue May 9 14:09:09 EDT 2000 Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Tue, 9 May 2000 13:59:47 -0400 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KTL8KRTY; Tue, 9 May 2000 13:59:44 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K365NYSZ; Tue, 9 May 2000 13:59:46 -0400 Message-ID: <391852DF.85596045@americasm01.nt.com> Date: Tue, 09 May 2000 14:03:11 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: albee Cc: sip Subject: Re: [SIP] Sip Grammar: Multiple entries References: <002301bfb9cd$5abec830$a27f01d9@pc127162.miel.mot.com> Content-Type: multipart/alternative; boundary="------------32759A86B827CA21CDB8F6F5" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------32759A86B827CA21CDB8F6F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It sounds like you're trying to apply a URI lexical analysis to SIP headers which isn't going to work too well for the reasons you've discovered. If you want to take this approach, I think you have to provide a more granular tokenizer and glue things back together, if necessary. I suspect most implementations perform context sensitive parsing, rather than try to do a context insensitive tokenization as a first step. Putting in additional spaces will force your tokenizer to work, but isn't at all backwards compatible with spec or existing implementations. Rick Albee Vimal wrote: > Thanks for responding to our doubts. Since the URI/addr-spec grammar > accepts alpha-numeric, ";" , "," , "=" etc. We find that during the > lexical analysis the rule/token that matches the maximum number of > input is returned hence ";action=proxy,gaya" is returned as a single > URI token, instead of being returned as contact-param ,a comma token > (comma token refers to ',') and display-name token (refers the > 'gaya'). Earlier we were trying to convey that if a space is > introduced we can avoid this situation and make token retrieval more > easy.Sorry, for giving an incomplete example it should have > been From:JerryHere since there is no > space between the ':' and 'Jerry', even though we specify rule to > return From as a separate token and ':' as another. The lexical > analyzer goes for the maximum pattern match and returns "From:Jerry" > as the URI/addr-spec token. The grammar works fine in identifying > as URI/addr-spec token. Had there been a space between > ':' and display-name "From:Jerry" would not be returned as a addr-spec > token. Yes, this can be overcome by having some special condition > checks and doing rescan. What we thought was this could be avoided if > a space is mandated in both the cases. ThanksAlbee Vimal-----Original > Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rick Workman > Sent: Tuesday, May 09, 2000 7:47 PM > To: Vivek Rao > Cc: sip@lists.research.bell-labs.com > Subject: Re: [SIP] Sip Grammer: Multiple entries > > > > > Vivek Rao wrote: > > > Hi > > The grammer for contact specified in RFC2543bis is > > as follows > > > > Contact = ("Contact"|"m")":" > > ("*"|(1#((name_addr|addr_spec) > > {*(";"contact-params)]))) > > name_addr = [display-name]"<"addr_spec">" > > addr_spec = SIP-URL|URI > > > > In the example below > > > > ontact:;action=proxy,gaya > > > > Since the grammar for URI field accepts a ';' , '=' & > > ',' , ";action=proxy,gaya" will be identified as a > > URI. Hence its required to scan through this to > > retrieve the Contact-Param. All this can be avoided if > > we allow a minimum of one space on either side of > > comma. > > My interpretation is the URI (or in this case SIP-URL) > completes when the ">" is encountered so the "action=proxy" > is parsed as a legal contact-param. So I don't understand > the problem. > > > > > Similar situation occurs for Via, Route & > > Record-Route. > > > > A similar situation occurs if a colon(:) is > > immediately followed by a display name as in From or > > To fields (e.g. From:Jerry). > > > > This one's a bit more problematical because "Jerry" is a > valid URI (a relativeURI), but then again almost anything > is. It can't be a display name because it's not followed by > a "<" addr-spec ">". However, I don't think inserting a > space helps, does it? (Inserting white space is always > allowed in headers, but only mandatory when header elements > need to be separated, i.e., between two tokens.) > > > > > Please clarify on this. > > Thanks > > Vivek > > > > __________________________________________________ > > Do You Yahoo!? > > Send instant messages & get email alerts with Yahoo! > > Messenger. > > http://im.yahoo.com/ > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > Rick Workman > Nortel Networks > Ottawa > --------------32759A86B827CA21CDB8F6F5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
It sounds like you're trying to apply a URI lexical analysis to SIP headers which isn't going to work too well for the reasons you've discovered. If you want to take this approach, I think you have to provide a more granular tokenizer and glue things back together, if necessary. I suspect most implementations perform context sensitive parsing, rather than try to do a context insensitive tokenization as a first step.

Putting in additional spaces will force your tokenizer to work, but isn't at all backwards compatible with spec or existing implementations.

Rick

Albee Vimal wrote:

 Thanks for responding to our doubts.  Since the URI/addr-spec grammar accepts alpha-numeric, ";" ,  "," , "=" etc. We find that during the lexical analysis the rule/token that matches the maximum number of input is returned  hence ";action=proxy,gaya" is returned  as a single URI token, instead of being returned as contact-param ,a comma token (comma token refers to ',') and display-name token (refers the 'gaya'). Earlier we were trying to convey that if a space is introduced we can avoid this situation and make token retrieval more easy.Sorry, for giving an incomplete example it should have been                   From:Jerry<sip:any@doubt>Here since there is no space between the ':' and 'Jerry', even though we specify rule to return From as a separate token and ':' as another. The lexical analyzer goes for the maximum pattern match and returns "From:Jerry" as the URI/addr-spec token.  The grammar works fine in identifying <sip:any@doubt> as URI/addr-spec token. Had there been a space between ':' and display-name "From:Jerry" would not be returned as a addr-spec token. Yes, this can be overcome by having some special condition checks and doing rescan. What we thought was this could be avoided if a space is mandated in both the cases. ThanksAlbee Vimal-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rick Workman
Sent: Tuesday, May 09, 2000 7:47 PM
To: Vivek Rao
Cc: sip@lists.research.bell-labs.com
Subject: Re: [SIP] Sip Grammer: Multiple entries
 
 

Vivek Rao wrote:

Hi
   The grammer for contact specified in RFC2543bis is
as follows

Contact   = ("Contact"|"m")":"
                 ("*"|(1#((name_addr|addr_spec)
{*(";"contact-params)])))
name_addr = [display-name]"<"addr_spec">"
addr_spec  = SIP-URL|URI

In the example below
Contact:<sip:tree@yahoo.com>;action=proxy,gaya<sip:someone@anwhere.com>

Since the grammar for URI field accepts a ';' , '=' &
',' , ";action=proxy,gaya" will be identified as a
URI. Hence its required to scan through this to
retrieve the Contact-Param. All this can be avoided if
we allow a minimum of one space on either side of
comma.

My interpretation is the URI (or in this case SIP-URL) completes when the ">" is encountered so the "action=proxy" is parsed as a legal contact-param. So I don't understand the problem.
 
Similar situation occurs for Via, Route &
Record-Route.

A similar situation occurs if a colon(:) is
immediately followed by a display name as in From or
To fields (e.g. From:Jerry).
 

This one's a bit more problematical because "Jerry" is a valid URI (a relativeURI), but then again almost anything is. It can't be a display name because it's not followed by a "<" addr-spec ">". However, I don't think inserting a space helps, does it? (Inserting white space is always allowed in headers, but only mandatory when header elements need to be separated, i.e., between two tokens.)
 
Please clarify on this.
Thanks
Vivek

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

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

Rick Workman
Nortel Networks
Ottawa
--------------32759A86B827CA21CDB8F6F5-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 15:36:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29187 for ; Tue, 9 May 2000 15:36:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A5344433D; Tue, 9 May 2000 15:29:51 -0400 (EDT) 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 E944D44336 for ; Tue, 9 May 2000 15:29:48 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 9 15:34:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3E91A44344; Tue, 9 May 2000 15:21:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1462044341 for ; Tue, 9 May 2000 15:21:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 632FF52C4; Tue, 9 May 2000 15:21:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 81D2F52B6 for ; Tue, 9 May 2000 15:21:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 9 15:20:48 EDT 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 9 15:20:47 EDT 2000 Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA20544 for ; Tue, 9 May 2000 15:20:46 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id PAA48812; Tue, 9 May 2000 15:20:45 -0400 (EDT) (envelope-from lennox) Date: Tue, 9 May 2000 15:20:45 -0400 (EDT) Message-Id: <200005091920.PAA48812@conrail.cs.columbia.edu> From: Jonathan Lennox To: Subject: RE: [SIP] Sip Grammar: Multiple entries In-Reply-To: <002301bfb9cd$5abec830$a27f01d9@pc127162.miel.mot.com> References: <39181DF5.1D7B2CA0@americasm01.nt.com> <002301bfb9cd$5abec830$a27f01d9@pc127162.miel.mot.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Tue, May 9 2000, "Albee Vimal" wrote to "'Rick Workman', sip@lists.research.bell-labs.com" saying: > Thanks for responding to our doubts. > Since the URI/addr-spec grammar accepts alpha-numeric, ";" , "," , "=" > etc. We find that during the lexical analysis the rule/token that matches > the maximum number of input is returned hence ";action=proxy,gaya" is > returned as a single URI token, instead of being returned as contact-param > ,a comma token (comma token refers to ',') and display-name token (refers > the 'gaya'). Earlier we were trying to convey that if a space is introduced > we can avoid this situation and make token retrieval more easy. The simplest solution to this is to drop ',' from the set of characters which is allowed to appear unescaped in a SIP URI, as Igor suggested a few days ago. I don't think this will cause much in the way of compatibility problems (though you SHOULD handle an unescaped comma in a URI correctly if it's between angle brackets, in a Request-URI, or whatever). > Sorry, for giving an incomplete example it should have been > From:Jerry > Here since there is no space between the ':' and 'Jerry', even though we > specify rule to return From as a separate token and ':' as another. The > lexical analyzer goes for the maximum pattern match and returns "From:Jerry" > as the URI/addr-spec token. The grammar works fine in identifying > as URI/addr-spec token. Had there been a space between ':' > and display-name "From:Jerry" would not be returned as a addr-spec token. > Yes, this can be overcome by having some special condition checks and doing > rescan. What we thought was this could be avoided if a space is mandated in > both the cases. This one, however, I don't think is a problem. Tracing down the grammar for the generic message-header syntax in 2543, we find: message-header = field-name ":" [ field-value ] CRLF field-name = token token = 1*< any CHAR except CTL's or separators> separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT Thus, ":" isn't allowed in a field-name, so the grammar is unambiguous. It looks like what you're trying to do is to have a separate tokenizer and parser (the usual lex/yacc split)? I don't think the SIP grammar will support that, unfortunately; it's too irregular at a low level. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 9 16:18:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00103 for ; Tue, 9 May 2000 16:18:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CD9AB44353; Tue, 9 May 2000 16:11:51 -0400 (EDT) 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 540344434A for ; Tue, 9 May 2000 16:11:49 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 9 16:16:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1992044345; Tue, 9 May 2000 16:03:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E2A8244341 for ; Tue, 9 May 2000 16:03:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 727B852C4; Tue, 9 May 2000 16:03:07 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B19A252B6 for ; Tue, 9 May 2000 16:03:04 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 9 16:02:40 EDT 2000 Received: from mail.Sophia.8x8.COM ([195.154.106.54]) by dusty; Tue May 9 16:02:39 EDT 2000 Received: from 8x8.com (symph210.8x8.com [207.82.37.210]) by mail.Sophia.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id WAA01737 for ; Tue, 9 May 2000 22:02:35 GMT Message-ID: <39186E23.D64EE308@8x8.com> Date: Tue, 09 May 2000 12:59:31 -0700 From: Marc Petit-Huguenin Organization: Netergy Networks - Advanced Telephony Solutions X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: IETF SIP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] draft 2543Bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Some comments on 2543Bis: In the SIP URL syntax (figure 3) the new user parameter "np-queried" is not defined. Also in the Client error status codes (figure 7), the 487 code is not defined. And somes questions: The second paragraph of the section 4.2.4 states that "the INVITE must be completed with a final response". But which response do we must use? A 487 like for a CANCEL or another response? The first paragraph of the same section does not explain when the sender of the BYE request must cease to transmit media streams. Is it when the BYE is sent or when the 200 is received? Thank you for your responses, -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@8x8.com "Everything I love is either immoral, illegal or makes you fat" _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 10 04:14:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20506 for ; Wed, 10 May 2000 04:14:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D350A4433D; Wed, 10 May 2000 04:07:46 -0400 (EDT) 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 01B7B44336 for ; Wed, 10 May 2000 04:07:43 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 10 04:12:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 03B7644344; Wed, 10 May 2000 03:59:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id CC9E144341 for ; Wed, 10 May 2000 03:59:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 34D8152C4; Wed, 10 May 2000 03:59:08 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 417E352B6 for ; Wed, 10 May 2000 03:59:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 10 03:57:50 EDT 2000 Received: from qhars002.nortel.com ([192.100.101.19]) by dusty; Wed May 10 03:57:49 EDT 2000 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Wed, 10 May 2000 08:57:33 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 May 2000 08:57:30 +0100 Message-ID: <61ABD11436FED21192440000F81F3E3603311AC4@nwcwi1a.europe.nortel.com> From: "Joshua Moloney" To: "'sip@lists.research.bell-labs.com'" Date: Wed, 10 May 2000 08:57:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBA55.63BC2788" Subject: [SIP] Comments on draft-ietf-sip-isup-mime-01 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFBA55.63BC2788 Content-Type: text/plain Hi all, Having skipped through the new release of the draft specifying the rules surrounding ISUP & QSIG MIME types, I have a question... It is my understanding that the Content-Transfer-Encoding header was primarily used to indicate that a message body had been transformed into a format that wasn't 8-bit clean (thanks to Jonathan R. for explaining that!). SIP is 8-bit clean (so I'm told!), so here's the rub - why is the Content-Transfer-Encoding header used to specify binary, when we know it's going to be binary anyway? Can't we ditch it? Cheers, Josh Moloney Nortel Networks ------_=_NextPart_001_01BFBA55.63BC2788 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-sip-isup-mime-01

Hi all,

Having skipped through the new release = of the draft specifying the rules surrounding ISUP & QSIG MIME = types, I have a question...

It is my understanding that the = Content-Transfer-Encoding header was primarily used to indicate that a = message body had been transformed into a format that wasn't 8-bit clean = (thanks to Jonathan R. for explaining that!). SIP is 8-bit clean (so = I'm told!), so here's the rub - why is the Content-Transfer-Encoding = header used to specify binary, when we know it's going to be binary = anyway? Can't we ditch it?

Cheers,

Josh Moloney
Nortel = Networks

------_=_NextPart_001_01BFBA55.63BC2788-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 10 05:18:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20801 for ; Wed, 10 May 2000 05:18:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A1FA144336; Wed, 10 May 2000 05:11:48 -0400 (EDT) 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 3AFB544348 for ; Wed, 10 May 2000 05:11:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 10 05:16:22 EDT 2000 Received: by lists.bell-labs.com (Postfix) id CB4EA44341; Wed, 10 May 2000 05:03:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9323144345 for ; Wed, 10 May 2000 05:03:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 42AB752AB; Wed, 10 May 2000 05:03:11 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0690652C4 for ; Wed, 10 May 2000 05:03:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 10 05:01:31 EDT 2000 To: sip@lists.research.bell-labs.com Date: Wed, 10 May 2000 05:01:30 -0400 Received: from smtp1.cluster.oleane.net ([195.25.12.16]) by dusty; Wed May 10 05:01:30 EDT 2000 Received: from oleane (dyn-1-1-114.Vin.dialup.oleane.fr [195.25.4.114]) by smtp1.cluster.oleane.net with SMTP id LAA04261; Wed, 10 May 2000 11:01:20 +0200 (CEST) Message-ID: <00e801bfba5d$8a828e40$0401a8c0@oleane.com> From: "Peter Lewis" Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com To: Subject: Implementing H.323 Date: Wed, 10 May 2000 10:55:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01BFBA6E.4A470340" 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 This is a multi-part message in MIME format. ------=_NextPart_000_00E5_01BFBA6E.4A470340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Implementing H.323 : conference=20 10-13 October 2000 CFP online at: http://www.upperside.fr/bah323.htm ------=_NextPart_000_00E5_01BFBA6E.4A470340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Implementing H.323 :=20 conference
10-13 October 2000
CFP online at:
http://www.upperside.fr/bah32= 3.htm
------=_NextPart_000_00E5_01BFBA6E.4A470340-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 10 07:13:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22372 for ; Wed, 10 May 2000 07:13:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D1FFA44341; Wed, 10 May 2000 07:07:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A145F44340 for ; Wed, 10 May 2000 07:07:10 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA09713; Wed, 10 May 2000 12:11:36 +0100 (BST) Message-ID: <39194334.A6998CA9@ubiquity.net> Date: Wed, 10 May 2000 12:08:36 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation X-Mailer: Mozilla 4.7 [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] Multicast UDP Authentication Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, The BIS draft modified paragraph 10.2.2 Multicast UDP, to include the 401 status code in the following sentence .... "To avoid response implosion, servers MUST NOT answer multicast requests with a status code other than 2xx, 401 or 6xx." Should the last sentence of the same paragraph also be modified to read ..... "A proxy or UAC SHOULD send a CANCEL on receiving the first 2xx, 401 or 6xx response to a multicast request" --- - Without the addition of the 401 to the above sentence, the UAC processing of multiple responses from a multicast request becomes confused, as a 401 can arrive first. Thanks In Advance Phil -- Phil Hoffer Ubiquity Software Corporation Software Developer Ubiquity House Tel: +44 (0) 1633-765600 Langstone Park Fax: +44 (0) 1633-765601 Newport NP18 2LH URL: 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 May 10 07:52:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23333 for ; Wed, 10 May 2000 07:52:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2261F44340; Wed, 10 May 2000 07:46:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from octavie.dagstuhl.de (octavie.dagstuhl.de [192.76.146.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1E4344336 for ; Wed, 10 May 2000 07:46:18 -0400 (EDT) Received: from cs.columbia.edu (dhcp10 [192.76.146.110]) by octavie.dagstuhl.de (8.9.2/8.9.2) with ESMTP id NAA23983; Wed, 10 May 2000 13:52:00 +0200 (CEST) Message-ID: <39194F37.3F8F5BF7@cs.columbia.edu> Date: Wed, 10 May 2000 07:59:51 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] Multicast UDP Authentication References: <39194334.A6998CA9@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Yes; changed. Phil Hoffer wrote: > > Hi, > > The BIS draft modified paragraph 10.2.2 Multicast UDP, to include > the 401 status code in the following sentence .... > > "To avoid response implosion, servers MUST NOT answer multicast > requests with a status code other than 2xx, 401 or 6xx." > > Should the last sentence of the same paragraph also be modified > to read ..... > > "A proxy or UAC SHOULD send a CANCEL on receiving the first 2xx, > 401 or 6xx response to a multicast request" > --- > - > > Without the addition of the 401 to the above sentence, the UAC > processing of multiple responses from a multicast request becomes > confused, as a 401 can arrive first. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 10 08:05:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23574 for ; Wed, 10 May 2000 08:05:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE4D34435B; Wed, 10 May 2000 07:58:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 10AB644359 for ; Wed, 10 May 2000 07:58:42 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA28597; Wed, 10 May 2000 13:03:07 +0100 (BST) Message-ID: <39194F47.ACEDF998@ubiquity.net> Date: Wed, 10 May 2000 13:00:07 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "sip@lists.bell-labs.com" Subject: Re: [SIP] Multicast UDP Authentication References: <39194334.A6998CA9@ubiquity.net> <39194F37.3F8F5BF7@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Henning, Thanks for the quick reply. Following on from this ..... I believe a decision was made post bake off to allow a registrar to return a 407, in response to a register request. This of course has implications with respect to the handling of multicast registers, as the paragraphs quoted only refer to 401. I think the options are to: a) Reverse the post bake off decision and state that a registrar SHOULD ONLY return 401 if it requires authentication. b) Modify the quoted paragraphs to also include a 407 response. What do you think? Thanks In Advance Phil Henning Schulzrinne wrote: > Yes; changed. > > Phil Hoffer wrote: > > > > Hi, > > > > The BIS draft modified paragraph 10.2.2 Multicast UDP, to include > > the 401 status code in the following sentence .... > > > > "To avoid response implosion, servers MUST NOT answer multicast > > requests with a status code other than 2xx, 401 or 6xx." > > > > Should the last sentence of the same paragraph also be modified > > to read ..... > > > > "A proxy or UAC SHOULD send a CANCEL on receiving the first 2xx, > > 401 or 6xx response to a multicast request" > > --- > > - > > > > Without the addition of the 401 to the above sentence, the UAC > > processing of multiple responses from a multicast request becomes > > confused, as a 401 can arrive first. > > -- Phil Hoffer Ubiquity Software Corporation Software Developer Ubiquity House Tel: +44 (0) 1633-765600 Langstone Park Fax: +44 (0) 1633-765601 Newport NP18 2LH URL: 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 May 10 09:40:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25968 for ; Wed, 10 May 2000 09:40:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6896544365; Wed, 10 May 2000 09:33:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 12D4C44359 for ; Wed, 10 May 2000 09:33:49 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA29435; Wed, 10 May 2000 14:38:13 +0100 (BST) Message-ID: <39196592.E2E579DD@ubiquity.net> Date: Wed, 10 May 2000 14:35:14 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "sip@lists.bell-labs.com" Subject: Re: [SIP] Multicast UDP Authentication References: <39194334.A6998CA9@ubiquity.net> <39194F37.3F8F5BF7@cs.columbia.edu> <39194F47.ACEDF998@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi again, Is it possible for a proxy server to proxy a multicast request? If so then that would suggest that Proxy-Authenticate (407) might be required in order to achieve this. Therefore option b) would seem reasonable. Thoughts?? Regards Phil Phil Hoofer wrote: > Hi Henning, > > Thanks for the quick reply. > > Following on from this ..... > > I believe a decision was made post bake off to allow a registrar to > return a 407, in response to a register request. > > This of course has implications with respect to the handling of multicast > registers, as the paragraphs quoted only refer to 401. > > I think the options are to: > > a) Reverse the post bake off decision and state that a registrar SHOULD > ONLY return 401 if it requires authentication. > > b) Modify the quoted paragraphs to also include a 407 response. > > What do you think? > > Thanks In Advance > Phil > > Henning Schulzrinne wrote: > > > Yes; changed. > > > > Phil Hoffer wrote: > > > > > > Hi, > > > > > > The BIS draft modified paragraph 10.2.2 Multicast UDP, to include > > > the 401 status code in the following sentence .... > > > > > > "To avoid response implosion, servers MUST NOT answer multicast > > > requests with a status code other than 2xx, 401 or 6xx." > > > > > > Should the last sentence of the same paragraph also be modified > > > to read ..... > > > > > > "A proxy or UAC SHOULD send a CANCEL on receiving the first 2xx, > > > 401 or 6xx response to a multicast request" > > > --- > > > - > > > > > > Without the addition of the 401 to the above sentence, the UAC > > > processing of multiple responses from a multicast request becomes > > > confused, as a 401 can arrive first. > > > -- Phil Hoffer Ubiquity Software Corporation Software Developer Ubiquity House Tel: +44 (0) 1633-765600 Langstone Park Fax: +44 (0) 1633-765601 Newport NP18 2LH URL: 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 May 10 12:09:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29074 for ; Wed, 10 May 2000 12:09:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D1994433E; Wed, 10 May 2000 12:03:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8282A44336 for ; Wed, 10 May 2000 12:03:18 -0400 (EDT) Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA08518; Wed, 10 May 2000 12:10:52 -0400 (EDT) Message-ID: <39198C61.CFFF750F@dynamicsoft.com> Date: Wed, 10 May 2000 12:20:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] Multicast UDP Authentication References: <39194334.A6998CA9@ubiquity.net> <39194F37.3F8F5BF7@cs.columbia.edu> <39194F47.ACEDF998@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Phil Hoffer wrote: > > Hi Henning, > > Thanks for the quick reply. > > Following on from this ..... > > I believe a decision was made post bake off to allow a registrar to > return a 407, in response to a register request. No. A registrar *terminates* the request. It does not proxy it. Therefore, it uses 401. A proxy which sends a REGISTER to a registrar is *proxying* the request, and thus uses 407, NOT 401. That was the clarification made during the bakeoff. > b) Modify the quoted paragraphs to also include a 407 response. Actually, the quoted paragraphs need to be modified to handle any response code for which a subsequent request is needed and requested. This includes 401, 407, and 484. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 14:43:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02049 for ; Wed, 10 May 2000 14:43:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A7ADA44348; Wed, 10 May 2000 14:36:30 -0400 (EDT) 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 0EE5444336 for ; Wed, 10 May 2000 14:36:28 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Wed, 10 May 2000 13:35:28 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K4DZ4T1Z; Wed, 10 May 2000 14:35:19 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K365N5BH; Wed, 10 May 2000 14:35:23 -0400 Message-ID: <3919ACC0.5D9BAB71@americasm01.nt.com> Date: Wed, 10 May 2000 14:38:56 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Cc: sip@lists.bell-labs.com Subject: Re: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax References: <3912C921.D7E42893@americasm01.nt.com> <200005051417.KAA19665@ind.cs.columbia.edu> <3912E862.2E967219@cs.columbia.edu> <200005051647.MAA21169@ind.cs.columbia.edu> <39130BEC.7273EAFE@americasm01.nt.com> <39135330.99B49770@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------9F7BF062EF6473DA11D8978A" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------9F7BF062EF6473DA11D8978A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In an attempt to get some closure on the SIP-URL header BNF, how about: headers = "?" header *("&" header) header = hname "=" hvalue hname = 1*(hname_char) hvalue = *(hvalue_char) hname_char = alphanum | "-" | "." | "!" | "*" | "_" | "+" | "'" | "~" hvalue_char = hvreserved | unreserved | escaped hvreserved = ";" | "/" | "?" | ":" | "@" | "=" | "+" |"$" Notes: 1. This isn't strictly backward compatible but I can't see any practical issues. (Same as proposed change to other-param?) 2. hname_char set is a subset of token (to be consistent with "field-name") which doesn't include "%" (URI "delims") or "`" (URI "unwise"). 3. hvreserved is a subset of the current reserved rule eliminating "&", "," as per earlier discussion, and "[" and "]" (both URI "unwise"). 4. Scanning the current header definitions, at least the following must be escaped: - any required LWS, e.g., for token separation or in rfc1123 dates - double quotes in quoted strings - "\" in quoted-pair (comments and quoted-strings) - "%" and "`" in tokens - "<" and ">" in name-addrs - "&" in any embedded SIP-URL headers - "," in # lists - any illegal characters in TEXT-UTF8 - any others? 5. Multi-byte UTF-8 characters will be represent by a 2*escaped , i.e., the UTF-8 character CA98 will escape to %CA%98. (I think this was the intent of Jonathan Lennox's previous proposal.) Also, I'd like to see the text concerning reserved characters and escaping clarified. If the BNF can be tightened up to the point where the allowable characters for any SIP-URL component have been clearly defined, then, by definition, any other characters must be escaped. Calling these other characters reserved confuses them with those in the "reserved" rule in the URI spec (and the current SIP RFC). Am I missing something? Rick Workman Nortel Networks Ottawa --------------9F7BF062EF6473DA11D8978A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
In an attempt to get some closure on the SIP-URL header BNF, how about:

headers     = "?" header *("&" header)
header      = hname "=" hvalue
hname       = 1*(hname_char)
hvalue      = *(hvalue_char)

hname_char  = alphanum | "-" | "." | "!" | "*" | "_" | "+" | "'" | "~"

hvalue_char = hvreserved | unreserved | escaped
hvreserved  = ";" | "/" | "?" | ":" | "@" | "=" | "+" |"$"
 

Notes:
1. This isn't strictly backward compatible but I can't see any practical issues. (Same as proposed change to other-param?)
2. hname_char set is a subset of token (to be consistent with "field-name") which doesn't include "%" (URI "delims") or "`" (URI "unwise").
3. hvreserved is a subset of the current reserved rule eliminating "&", "," as per earlier discussion, and "[" and "]" (both URI "unwise").
4. Scanning the current header definitions, at least the following must be escaped:
   - any required LWS, e.g., for token separation or in rfc1123 dates
   - double quotes in quoted strings
   - "\" in quoted-pair (comments and quoted-strings)
   - "%" and "`" in tokens
   - "<" and ">" in name-addrs
   - "&" in any embedded SIP-URL headers
   - "," in # lists
   - any illegal characters in TEXT-UTF8
   - any others?
5. Multi-byte UTF-8 characters will be represent by a 2*escaped , i.e., the UTF-8 character CA98 will escape to %CA%98. (I think this was the intent of Jonathan Lennox's previous proposal.)
 

Also, I'd like to see the text concerning reserved characters and escaping clarified. If the BNF can be tightened up to the point where the allowable characters for any SIP-URL component have been clearly defined, then, by definition, any other characters must be escaped. Calling these other characters reserved confuses them with those in the "reserved" rule in the URI spec (and the current SIP RFC). Am I missing something?
 

Rick Workman
Nortel Networks
Ottawa --------------9F7BF062EF6473DA11D8978A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 10 18:03:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04294 for ; Wed, 10 May 2000 18:03:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A29684433F; Wed, 10 May 2000 17:56:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EE50A44336 for ; Wed, 10 May 2000 17:56:47 -0400 (EDT) Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA10152; Wed, 10 May 2000 18:00:41 -0400 (EDT) Message-ID: <3919DE5C.F344934@dynamicsoft.com> Date: Wed, 10 May 2000 18:10:36 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Clarification to Figure 13 Bis Draft References: <39129CE6.3173994@ubiquity.net> <39164E6A.EBD15785@dynamicsoft.com> <39167DDA.910883E2@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Phil Hoffer wrote: > > > > 2) A transition from Failure state to Initial state is shown on the diagram, as > > > a dashed line. Unfortunately, this transition is unlabelled. I'm referring > > > to the left hand dashed line, not the BYE event which joins the Success > > > dashed line. > > > > Hmm. not sure, actually. The labeling would make this appear to be > > CANCEL, but thats not correct. Henning? > > Presumably this unlabelled event could be a CANCEL as they UAC > might have issued the CANCEL when the UAS was in Call Proceeding > state. So the >= 300 response could cross the incoming CANCEL on > the wire. Therefore a CANCEL could arrive in the Failure state. ??!! Yes, but in this case the next state is not Initial. You've already sent the response, and need to retransmit until the ACK comes. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 18:06:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04317 for ; Wed, 10 May 2000 18:06:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A1ABA4434D; Wed, 10 May 2000 17:59:41 -0400 (EDT) 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 0A2764434C for ; Wed, 10 May 2000 17:59:39 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 10 18:04:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A3CB144344; Wed, 10 May 2000 17:51:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7C9AB44341 for ; Wed, 10 May 2000 17:51:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4983A52C4; Wed, 10 May 2000 17:51:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 88A1652B6 for ; Wed, 10 May 2000 17:51:07 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed May 10 17:50:48 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 10 17:50:47 EDT 2000 Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA10108; Wed, 10 May 2000 17:52:02 -0400 (EDT) Message-ID: <3919DC55.74CF7F33@dynamicsoft.com> Date: Wed, 10 May 2000 18:01:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Sip Grammar: Multiple entries References: <39181DF5.1D7B2CA0@americasm01.nt.com> <002301bfb9cd$5abec830$a27f01d9@pc127162.miel.mot.com> <200005091920.PAA48812@conrail.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > On Tue, May 9 2000, "Albee Vimal" wrote to "'Rick Workman', sip@lists.research.bell-labs.com" saying: > > > Thanks for responding to our doubts. > > Since the URI/addr-spec grammar accepts alpha-numeric, ";" , "," , "=" > > etc. We find that during the lexical analysis the rule/token that matches > > the maximum number of input is returned hence ";action=proxy,gaya" is > > returned as a single URI token, instead of being returned as contact-param > > ,a comma token (comma token refers to ',') and display-name token (refers > > the 'gaya'). Earlier we were trying to convey that if a space is introduced > > we can avoid this situation and make token retrieval more easy. > > The simplest solution to this is to drop ',' from the set of characters > which is allowed to appear unescaped in a SIP URI, as Igor suggested a few > days ago. I don't think this will cause much in the way of compatibility > problems (though you SHOULD handle an unescaped comma in a URI correctly if > it's between angle brackets, in a Request-URI, or whatever). I still don't get how your analyzer figured that ;action=proxy,gaya is a URI. Was sip:tree@yahoo.com picked up as a URI? If so, the grammar clearly requires a comma between these two. In any case, I really don't want to mandate white space between tokens and separators, particularly in random select places like this. The rule for white space is generic and applies everywhere. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 18:21:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04442 for ; Wed, 10 May 2000 18:21:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9931E44357; Wed, 10 May 2000 18:15:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2126144356 for ; Wed, 10 May 2000 18:15:23 -0400 (EDT) Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA10254; Wed, 10 May 2000 18:22:45 -0400 (EDT) Message-ID: <3919E388.A317ECAC@dynamicsoft.com> Date: Wed, 10 May 2000 18:32:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rick Workman Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] URI's in SIP messages References: <200005081932.OAA06333@b04a45.exu.ericsson.se> <39173AAA.E5B25BC7@americasm01.nt.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rick Workman wrote: > > > > Sean Olson wrote: > > > > The current SIP BNF allows the general form of URI (or > > URI-reference?) to > > > be used in the request line and various headers. Observations and > > > questions: > > > > > > 1. A valid form of URI (RFC 2396)is the empty sequence since: > > > > > > URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] > > > > > > This would permit the request line and various headers (To, From, > > > Contact. ..) without an address specification which doesn't seem > > to make > > > much sense. RFC 2396 specifies that the empty sequence URI refers > > to the > > > start of the current document; is there any corresponding > > abstraction for > > > SIP transcations? > > > > No. Please god no. Obviously RFC2396 specifies a much wider and more > > abstract form > > of URI than is commonly used in SIP. Not everything in 2396 is > > appropriate for > > every URI scheme. They are a set of guidelines that work more or > > less for the most > > common URI schemes in use today: http, ftp, telnet, mailto (with > > some quirks), etc. > > > > Be that as it may, they're guidelines which are now an integral part > of the SIP BNF. Actually, this doesn't seem to be the case. The BNF for request URI, for example, is never defined in RFC2543! It says in section 4.3 thats its either a SIP URI or general URI. The BNF for addr-spec (used in To, From, Contact) is defined as SIP-URL or URI, but I also never found the BNF for URI. Even rfc2396 doesn't define "URI", but rather absoluteURI, relativeURI or URI-reference. I believe what URI really means in the SIP context is absoluteURI. That is, there must always be a scheme, followed by a colon. I believe this eliminates many of the ambiguities people have been raising. I'm not a big fan of relative URIs within HTTP itself (as opposed to within HTML, where the browser computes the absolute URI and puts that in the HTTP request); in general, I believe URIs sent on the wire should be globally resolvable. HTTP ran into all sorts of problems, as I recall, since URIs were not always absolute, and thus servers that supported many domains got confused when they received things like GET index.html HTTP/1.0. > > > > > > > > > > > 2. The relative URI references a resource relative to a base URI > > of a > > > hierarchial scheme. So a similar question: is this a useful > > concept for > > > SIP sessions? > > > > > > > The only contexts where I would think this might be useful would be > > in > > 1) The headers parameter of a SIP URI (for the From: and possibly > > To: headers) > > 2) A SIP "cookie" similar to an HTTP-cookie. This hasn't really been > > investigated > > much but would be interesting. > > > > In other words, I don't think it is generally useful in the usual > > places in a SIP > > message (To/From/Contact/Request-URI). But it is potentially useful > > at the user interface > > level or as part of some service logic. > > As part of a SIP message? I guess I can think of many examples where > you want to map user friendly "addresses" to URI's in SIP messages, > but that's out of scope for this discussion. I really don't see the use of relative URIs within SIP itself. > > > > > > > > 3. Finally RFC 2396 states (my emphasis): > > > "When a URI reference is used to perform a retrieval action on > > the > > > identified resource, the optional fragment identifier, > > separated from > > > the URI by a crosshatch ("#") character, consists of additional > > > > > reference information to be interpreted by the user agent after > > the > > > retrieval action has been successfully completed. As such, it > > is not > > > part of a URI, but is often used in conjunction with a URI." > > > > > > > True, but this treated in very different ways by different web > > browsers. Some > > treat it as part of the URI, others use it for "post-processing". > > It's not really used in a standard way for SIP, but as stated above > > it really is up > > to the UserAgent's interpretation. THIS IS A GOOD THING. > > I'm not arguing the merits of the URI syntax, just how it's used in > SIP messages. Again, if we say that URI = absoluteURI, this problem goes away also. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 18:50:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04641 for ; Wed, 10 May 2000 18:50:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D285E4434C; Wed, 10 May 2000 18:43:41 -0400 (EDT) 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 49E3744336 for ; Wed, 10 May 2000 18:43:39 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 10 18:48:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id EA3B044344; Wed, 10 May 2000 18:35:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C390544341 for ; Wed, 10 May 2000 18:35:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C077C52C4; Wed, 10 May 2000 18:35:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C40A652AB for ; Wed, 10 May 2000 18:35:07 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 10 18:34:31 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 10 18:34:30 EDT 2000 Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA10350; Wed, 10 May 2000 18:35:40 -0400 (EDT) Message-ID: <3919E68F.9DAE06D9@dynamicsoft.com> Date: Wed, 10 May 2000 18:45:35 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: albee@miel.mot.com Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Some clarifications on action field in Contact References: <002201bfb9c9$2dd67e20$a27f01d9@pc127162.miel.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Albee Vimal wrote: > > Hi > We have some doubts on the action parameter that is associated with a > Contact field. > 1.We would like to know what it means when we register with action= redirect > or proxy. Does it mean that if a registration is made with action=redirect, > then on receiving an INVITE destined to the registered location, network > server sends a 3XX response to the UAC with all the new contact locations in > the Contact field. The UAC then sends INVITE to all the new locations > mentioned in the Contact field. It doesn't have to send the INVITE to all the new locations, but besides that, yes. > > 2. This is valid only if an UAC can send redirected INVITE to multiple > locations. UAC while forwarding a redirected INVITE replaces the Request-URI > with the received Contact addresses. If one of the redirected endpoints > responds with a 2XX response, the UAC will be able to forward an ACK to the > Contact field coresponding to it (since the RFC's mandates that a 2XX > response to INVITE contain a Contact field (6.13, Pg. 39)). But is'nt it > mandatory for an endpoint sending a 6XX response to insert a Contact field > as well. The rules here for sending ACK are the same for any other case. You build the Route header as you normally would (consisting of the Contact and/or Record-Route headers), and use that. If there wasn't a Contact or Record-Route, the ACK goes to the same place the INVITE went to. > > 3. This is related to 2. On receiving a >3XX response from one of the > endpoints how will the UAC identify the location to which it has to send an > ACK. i.e how would this response be matched with a request transaction, > since the request was sent to multiple destinations. Branch id in the via header, just like a forking proxy. > > 4. In "16.6 Redirects" example in the RFC we find two Cseq fields in the 302 > response. We would like to know whether it is allowed to have multiple CSeq > fields. Oops. This is wrong. Only one CSeq is allowed. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 18:52:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04652 for ; Wed, 10 May 2000 18:52:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C74BD4436C; Wed, 10 May 2000 18:45:41 -0400 (EDT) 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 56FCB4436A for ; Wed, 10 May 2000 18:45:39 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 10 18:50:17 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3354044345; Wed, 10 May 2000 18:37:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 089B244341 for ; Wed, 10 May 2000 18:37:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id ED23852C4; Wed, 10 May 2000 18:37:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id EABAD52AB for ; Wed, 10 May 2000 18:37:07 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed May 10 18:35:51 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 10 18:35:50 EDT 2000 Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA10298; Wed, 10 May 2000 18:31:01 -0400 (EDT) Message-ID: <3919E578.9FCE6061@dynamicsoft.com> Date: Wed, 10 May 2000 18:40:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Manoj Bhatia Cc: archow@hss.hns.com, "Adam B. Roach" , sip@lists.research.bell-labs.com, stlevy@cisco.com References: <6525689E.0030D6CF.00@sampark.hss.hns.com> <38CF11A4.F04178D4@dynamicsoft.com> <391730F3.65CB61DF@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Two New Drafts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Manoj Bhatia wrote: > > Hi Jonathan > > Can we at least draw some consensus on the 'Meesage Waiting > Indication(MWI)' > event in Voice mail context ? I think there is a clear need for subscription and notification events for many things, including message waiting indication. The question is how to structure this in the most general way. I really don't want a specific and separate spec just for MWI, as it seems to narrow. > > Further, in one of the threads on this list, Henning says that we must > adopt > drafts/discussion on PINT to decide on MWI. To me, what this means is that: 1. we use the SUBSCRIBE and NOTIFY methods 2. the body is used to define the object being subscribed to > > Also, there is some concern that whether SUBSCRIBE - a new SIP method > > should be used for sending subscription requests or is REGISTER a good > way of doing that ? Definitely not REGISTER. Its semantics are completely different. It updates a binding, in a server, of the address in the To with the addresses in the Contact. I don't see at all how this accomplishes MWI. > > My concern is that very soon you may have interop problems with > SUBSCRIBE/ > REGISTER method being used by vendors in different ways . You should absolutely not be using REGISTER for this. > > Is SUBSCRIBE/NOTIFY the de facto way for MWI implementation ? I think it is clearly the basis. The question, again, is how to do this generally. Some of the questions in my mind are: 1. how do we handle addressing? I.e., what is the entity that is being subscribed to, in the request URI, for mwi? Is it even a SIP URL? 2. What is the format of the content in the body for mwi? Is there a format which is more generic than just mwi? 3. What is the format of the content in notifications? 4. security issues - how do you prevent attacks whereby I subscribe to some events, and list someone else in the Contact, say, to receive the notifications? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 19:04:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04764 for ; Wed, 10 May 2000 19:04:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 73B954434C; Wed, 10 May 2000 18:58:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1B78344336 for ; Wed, 10 May 2000 18:58:01 -0400 (EDT) Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA10407; Wed, 10 May 2000 19:01:54 -0400 (EDT) Message-ID: <3919ECB5.A51811E9@dynamicsoft.com> Date: Wed, 10 May 2000 19:11:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] Multicast UDP Authentication References: <39194334.A6998CA9@ubiquity.net> <39194F37.3F8F5BF7@cs.columbia.edu> <39194F47.ACEDF998@ubiquity.net> <39196592.E2E579DD@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Phil Hoffer wrote: > > Hi again, > > Is it possible for a proxy server to proxy a multicast request? Of course. > > If so then that would suggest that Proxy-Authenticate (407) might > be required in order to achieve this. > > Therefore option b) would seem reasonable. Yes. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 19:10:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04811 for ; Wed, 10 May 2000 19:10:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 187144433A; Wed, 10 May 2000 19:03:41 -0400 (EDT) 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 E689344341 for ; Wed, 10 May 2000 19:03:38 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 10 19:08:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E77A444344; Wed, 10 May 2000 18:55:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C01BE44341 for ; Wed, 10 May 2000 18:55:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B55D452C4; Wed, 10 May 2000 18:55:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E714A52AB for ; Wed, 10 May 2000 18:55:07 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 10 18:54:11 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 10 18:54:11 EDT 2000 Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA10383; Wed, 10 May 2000 18:55:25 -0400 (EDT) Message-ID: <3919EB30.4234F589@dynamicsoft.com> Date: Wed, 10 May 2000 19:05:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marc Petit-Huguenin Cc: IETF SIP Subject: Re: [SIP] draft 2543Bis References: <39186E23.D64EE308@8x8.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Marc Petit-Huguenin wrote: > > Hi, > > Some comments on 2543Bis: > > In the SIP URL syntax (figure 3) the new user parameter "np-queried" is > not defined. Was there consensus this was the right way to do this? I recall we were looking for something maybe more general, but I don't think the discussion converged. > And somes questions: > > The second paragraph of the section 4.2.4 states that "the INVITE must > be completed with a final response". But which response do we must use? > A 487 like for a CANCEL or another response? Doesn't actually matter. 4xx is probably fine. > > The first paragraph of the same section does not explain when the sender > of the BYE request must cease to transmit media streams. Is it when the > BYE is sent or when the 200 is received? Practically speaking, if a UA sends a BYE, the user wants to end the call, so you should probably stop sending audio right away. However, the SIP machinery still needs to hang on for a bit. Its possible that a BYE can generate a 5xx response with a retry-after; this can happen in a particular condition when the UAS answers the phone and hangs up immediately, and then the 200 OK and BYE pass on the wire. The caller gets the BYE before getting the 200, and can't match it to a call leg since it hasn't gotten the tag in the To yet to its original INVITE. So, the right thing to do is respond to the BYE with retry-after to give the 200 OK a chance to arrive. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 19:16:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04852 for ; Wed, 10 May 2000 19:16:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 340174433A; Wed, 10 May 2000 19:09:41 -0400 (EDT) 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 AAE1544339 for ; Wed, 10 May 2000 19:09:38 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 10 19:14:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D5D6844345; Wed, 10 May 2000 19:01:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id AE05544341 for ; Wed, 10 May 2000 19:01:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A5F2D52C4; Wed, 10 May 2000 19:01:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EA5F652AB for ; Wed, 10 May 2000 19:01:08 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 10 18:59:23 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed May 10 18:59:22 EDT 2000 Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA10395; Wed, 10 May 2000 19:00:36 -0400 (EDT) Message-ID: <3919EC67.6DCD7A08@dynamicsoft.com> Date: Wed, 10 May 2000 19:10:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Moloney Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: [SIP] Comments on draft-ietf-sip-isup-mime-01 References: <61ABD11436FED21192440000F81F3E3603311AC4@nwcwi1a.europe.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Yes, I believe it should be removed. -Jonathan R. > Joshua Moloney wrote: > > Hi all, > > Having skipped through the new release of the draft specifying the > rules surrounding ISUP & QSIG MIME types, I have a question... > > It is my understanding that the Content-Transfer-Encoding header was > primarily used to indicate that a message body had been transformed > into a format that wasn't 8-bit clean (thanks to Jonathan R. for > explaining that!). SIP is 8-bit clean (so I'm told!), so here's the > rub - why is the Content-Transfer-Encoding header used to specify > binary, when we know it's going to be binary anyway? Can't we ditch > it? > > Cheers, > > Josh Moloney > Nortel Networks -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 20:53:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05562 for ; Wed, 10 May 2000 20:53:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A57E44341; Wed, 10 May 2000 20:46:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1114A44336 for ; Wed, 10 May 2000 20:46:46 -0400 (EDT) Received: from dynamicsoft.com (1Cust5.max1.par2.fra.da.uu.net [195.129.10.5]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA10663 for ; Wed, 10 May 2000 20:54:25 -0400 (EDT) Message-ID: <391A0713.5A7AC492@dynamicsoft.com> Date: Wed, 10 May 2000 21:04:19 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Minutes of SIP Security task force in Adelaide Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Folks, Enclosed are draft minutes of the SIp security task force meeting in Adelaide. Remember, "consensus" here does not represent consensus of the working group and this should be looked at more as a first step discussion. Thanks to Flemming for taking and preparing these minutes. -Jonathan R. Minutes of SIP Security Task Force meeting ========================================== 47th IETF meeting, Adelaide Prepared by Flemming Andreasen A number of people participated in the SIP Security Task Force meeting in Adelaide on Sunday 3/25/00 before the IETF meeting started. The purpose of the meeting was to start discussion on SIP security. 1. Goal ======= The following goals were established for the meeting: - Identify threats, what are the problems we are trying to solve: o Authorization of callers, user-user authentication model o SIP for secure media streams, encryption of media streams The following goal was suggested as well, however it was decided it may not be in scope for now: - Keying material for other things, e.g. for QoS admission It was then decided to divide the security discussion into two separate areas: - Encryption - Authentication 2. ENCRYPTION ============= End-to-end encryption only works in the simplest cases. SIP never really looked at security from a system perspective, only from a relatively simple protocol perspective. A discussion about threats and trust models was therefore initiated. There are two types of attacks to worry about: - User attacks - Rogue proxies Rogue proxies are: - Proxies that do not do what they are supposed to do, e.g. maintain privacy - Proxies that do things they are not supposed to, e.g. claim that calls occur when they didn’t by originating INVITEs. The rogue proxy issue led to a basic question; to what extent do you actually trust that a proxy does what it’s supposed to ? It was agreed that it would be very complicated if you trust the proxy to do some things, but not others, and hence the model would be to either trust the proxy or not. Furthermore, it was suggested, that trust would be either hop-by-hop or end-to-end (not, e.g., trust the next two hops). This led to a decision, that we need a model that does not depend on end-to-end security, but allows for it, while still providing a useful security service. The model for this will be to have hop-by-hop security with transitivity of trust and still allow for end-to-end security. As an added requirement on the hop-by-hop security trust model, it was also decided, that should a proxy route over an untrusted hop, the caller can request the call be rejected rather than continue with the call. This decision led to a long discussion about whether it works similarly the other way, i.e., can the called party decide to reject a call that has traversed an untrusted hop. It was eventually agreed, that it does work similarly the other way. However, the only thing you can do when a message has traversed an untrusted hop is to say that the entire message is untrusted (e.g., cannot say that certain fields are trusted and others are not). It was agreed to use the above as the foundation for the security model for encryption. A discussion on encryption mechanisms then started. Jonathan Rosenberg opened the discussion by suggesting that: - SIP encryption (not authentication) should be deprecated, because: o It doesn’t work with NAT and firewalls o It assumes you know the public key of the party you are calling, which is not a good assumption. o It only really hides the body (and again that doesn’t work well due to the above). Initial discussion of these points led to the decision that it should still be possible to support end-to-end encryption as there may be some uses for it. A problem with the current end-to-end encryption scheme is, that it relies on knowing the public key of the other party. One way of solving that is to return a public key in the response and simply do a re-INVITE then. However, it was agreed that we should not do that, as we effectively end up duplicating IKE, or something similar. Dave Oran suggested that end-to-end information that needs encryption should simply go in the body (don’t encrypt headers). We could use multipart for this, or simply allow for a single body to be encrypted and define an error code to be returned if the proxy needs to see the body (e.g. if SDP is encrypted and message traverses a firewall). The group decided to accept this mechanism. The error code will only support coarse granularity, i.e., if multiple bodies are encrypted, you will not be told which one is needed in clear, just a general error saying “body not understood”. Additional discussion on encryption of headers ensued. Contact is an example of header that can be usefully encrypted (end-to-end), but in general, there doesn’t seem to be a whole lot of use for this (generally, if the information is relevant it can’t be encrypted). Only want the registrar to see the Contact, not any of the intermediate proxies. It was then proposed, that rather than having the present encryption mechanism, we only encrypt bodies. For those rare SIP headers that you would want to encrypt end-to-end you may want to have some kind of “SIP-header” body part encrypted with e.g. S/MIME (although S/MIME is not viewed upon favorably by security people). PGP is there now, but it is not usefully deployable. This concluded the encryption discussion with the following recap of the encryption requirements identified: - Support encryption of some headers (Contact is the one useful example so far). - Prefer encrypted headers (not headers with encrypted content) to end up in body-parts rather than in SIP header. - Some bodies may have to be encrypted (not necessarily all) - Be able to send INVITE without end-to-end security, get some kind of response back from remote party telling you to do it securely, and re-issue INVITE (w. security this time). Not clear what the exact mechanism is for this, e.g., return public-key, certificate, or something outside of SIP. - Be able to send INVITE with end-to-end security first time around. 3. AUTHENTICATION (end-to-end) ============================== We have the following potential authentication requirements: - Called party id - Calling party id - Who we thought we were calling It is not clear there is any way to achieve this reliably (securely) unless we have end-to-end authentication. The problem with end-to-end authentication is, that it implies we (a proxy) cannot rewrite any of the information. Brian Rosen wanted to have SIP carry some information that allows/supports end-to-end authentication. Dean Willis wanted to transport messages across untrusted proxies and be able to detect what (and how) a message was altered/rewritten. Dean noted that there are three possibilities for what can happen to a message: - It is not modified - It is modified - Parts of it are deleted It was then suggested that From, To, and Bodies should be authenticated, however agreement was not achieved on this. Dave Oran then noted that X.400 had solved similar issues and pointed out the parallels to headers, bodies and envelopes. It was suggested that we adopt a similar model. This lead to the following tentative decision (not clear if this was in fact agreed to, however nobody objected): - SIP headers are hop-by-hop (period) - Anything above the auth header may be modified hop-by-hop - Anything below the auth header is end-to-end (allow for duplication of fields, e.g. To and From ) and cannot be modified. 3.1 Hop-by-hop Authentication ============================= Based on the above, the discussion then moved on to focus on hop-by-hop authentication. It was stated that, that we cannot assume availability of public key cryptography on an end-system (UA), however we can assume that proxies have public key cryptography support. It was furthermore stated that, we want to differ between security for: - Server to server - Client to server Currently SIP does not specify how you do hop-by-hop security, only that you can do it. We want to have at least one mechanism specified in the SIP specification. It was decided that we should have the following hop-by-hop security mechanisms: - Server to server: IPSec using ESP transport, - Client to server: IPSec using ESP transport (not clear ESP transport was agreed to) It was then suggested (however Jonathan Rosenberg did not want to declare consensus yet), that the following keying/authentication mechanisms should be used: - Server to server: Kerberos (with PKCROSS between realms) - Client to server: Kerberos (either with shared keys or PKINIT) The question about whether we need (hop-by-hop) authentication for both devices and applications was then asked. It was agreed that we only need it for applications as we can always have a default user on the device if no “real” user is logged in. The Security Association established identifies the user. For a gateway, the “user” is the gateway. For a device with multiple users on it, the device itself will then have to authenticate the users, unless you have a separate Security Association for every single user (which you probably don’t want to). Dean Willis and Robert Sparks objected that you need app-level security when you don’t have transitivity of trust, and there are applications where you do not have transitivity of trust. For example, consider a call where you involve multiple providers for that call (multi-proxy authenticate). Basically, it’s not enough to have either end-to-end or hop-by-hop security; you also need to have end-to-intermediate security. This was a different model than had been worked on for the majority of the meeting however no one argued against the validity of it. Since it contradicts some of the earlier assumptions and decisions made during the meeting, each of these will have to be revisited. 4. Miscellaneous ================ In addition to the above, the following security related issues were raised as well: 4.1 Areas needing further work ============================== - Challenge-response doesn’t work with forking (but addresses replay) as only one 401 will get back to the caller. - Want to have a security scheme that works with forking (but may not address replay). 4.2 CANCEL security =================== - If we have hop-by-hop security and we only accept CANCEL from previous hop, is CANCEL security hole then closed ? -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 10 21:02:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05657 for ; Wed, 10 May 2000 21:02:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B4D794433C; Wed, 10 May 2000 20:55:40 -0400 (EDT) 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 1AA8B44339 for ; Wed, 10 May 2000 20:55:38 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 10 21:00:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5D0DF44344; Wed, 10 May 2000 20:47:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 344C044341 for ; Wed, 10 May 2000 20:47:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DD4BA52C4; Wed, 10 May 2000 20:47:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1AB2152AB for ; Wed, 10 May 2000 20:47:08 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 10 20:45:29 EDT 2000 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by dusty; Wed May 10 20:45:28 EDT 2000 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 RAA13005; Wed, 10 May 2000 17:45:31 -0700 (PDT) Received: from buckthorn-nt (dhcp-171-69-93-65.cisco.com [171.69.93.65]) by imop.cisco.com (Mirapoint) with ESMTP id AAA92204; Wed, 10 May 2000 17:42:49 -0700 (PDT) Message-Id: <4.2.0.58.20000510170042.00c42900(null)> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 10 May 2000 17:45:07 -0700 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: [SIP] Re: Two New Drafts Cc: Manoj Bhatia , archow@hss.hns.com, "Adam B. Roach" , sip@lists.research.bell-labs.com, stlevy@cisco.com In-Reply-To: <3919E578.9FCE6061@dynamicsoft.com> References: <6525689E.0030D6CF.00@sampark.hss.hns.com> <38CF11A4.F04178D4@dynamicsoft.com> <391730F3.65CB61DF@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan, I'm proposing some strawman answers to your questions below... At 03:40 PM 5/10/00 , Jonathan Rosenberg wrote: >... > > Can we at least draw some consensus on the 'Message Waiting > > Indication(MWI)' > > event in Voice mail context ? > >I think there is a clear need for subscription and notification events >for many things, including message waiting indication. The question is >how to structure this in the most general way. I really don't want a >specific and separate spec just for MWI, as it seems to narrow. > > > Further, in one of the threads on this list, Henning says that we must > > adopt > > drafts/discussion on PINT to decide on MWI. > >To me, what this means is that: > >1. we use the SUBSCRIBE and NOTIFY methods >2. the body is used to define the object being subscribed to What about an explicit UNSUBSCRIBE method (pint), vs. using SUBSCRIBE with an "Expires: 0" header(subscribe/notify draft)? Why is a body strictly needed if you can express the symantics clearly in the Request-URI and an Event header? for example: Event: mailbox-summary >You should absolutely not be using REGISTER for this. I wholeheartedly agree! >Some of the questions in my mind are: > >1. how do we handle addressing? I.e., what is the entity that is being >subscribed to, in the request URI, for mwi? Is it even a SIP URL? I could imagine any of the following: sip:rohan@cisco.com sip:rohan@voicemail-server.cisco.com sip:rohan@cisco.com?Accept-Contact=*,feature=voice-mail mailto:rohan@cisco.com (if my voicemail is stored on my email server) In the first case, the event relates to a user who has a SIP presence. In the next, the event relates to my account on my voicemail server. In the third, the event relates to my "voice-mail" SIP feature. In the fourth, the event relates to my mail account. I think that generically this could be left to implementation, but that the WG should provide guidelines. Recommended SIP URI naming conventions in general are still pretty undefined. >2. What is the format of the content in the body for mwi? Is there a >format which is more generic than just mwi? Generically, I think we want "message summary" information. Alternatively, we may want to know only that there are new messages or not (simple boolean status, like biff). While this is very simple and good enough for some UAs, I don't want this to be the only recommended way to do MWI. A message summary would enable much richer uses, like this message on my display: "You have 3 new, and 7 old voice messages" or " *3*/7 voice, *25*/270 email " Does anyone else have thoughts on this? >3. What is the format of the content in notifications? Manoj, Ilya, and Shail proposed a simple plain-text format. Does anyone have specific complaints about it? I originally proposed an XML-based format, but it required a much heavier parser. Does anyone have an alternate proposal? >4. security issues - how do you prevent attacks whereby I subscribe to >some events, and list someone else in the Contact, say, to receive the >notifications? The same way we prevent unauthorized third-parties from REGISTERing with someone else in Contact to receive their invites. ;-) 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 May 11 08:48:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26258 for ; Thu, 11 May 2000 08:48:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE77544337; Thu, 11 May 2000 08:41:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 9EF7544336 for ; Thu, 11 May 2000 08:41:47 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA02952; Thu, 11 May 2000 13:46:04 +0100 (BST) Message-ID: <391AAB8B.B29E7C36@ubiquity.net> Date: Thu, 11 May 2000 13:46:03 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.61 [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] Expires header vs expires Contact param Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think there could be scope for minor confusion over the intended use of Expires header and Contact expires param in responses to REGISTER requests. In the response to a REGISTER section 4.2.6 of the bis draft states that an Expires header or expires Contact Param should be used to indicate the time at which the registration will be dropped. To me this can be taken to mean the two can be interchangeable and so presumably we are are talking about the time a new Contact contained in the REGISTER will be dropped. However, in section 6.22 it says that the Expires header is used in the the response to a REGISTER to indicate the earliest expiry time of all registrations. Furthermore is it correct to say that in the response to a REGISTER, where active registrations already existed, the Expires header cannot be used to indicate the time the new registration will be dropped and so an expire Contact param has to be used. If so what is the point in a server which adds expires Contact params to all active Contacts also adding an Expires header to indicate the earliest expiry time of all registrations. Cheers, Neil. -- Ubiquity Software Corporation 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 Thu May 11 09:10:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26944 for ; Thu, 11 May 2000 09:10:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 95C5944340; Thu, 11 May 2000 09:04:05 -0400 (EDT) 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 6B6104433F for ; Thu, 11 May 2000 09:03:58 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Thu, 11 May 2000 08:04:09 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K4DZW2S3; Thu, 11 May 2000 09:04:00 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K365N5V5; Thu, 11 May 2000 09:04:04 -0400 Message-ID: <391AB09F.917BD671@americasm01.nt.com> Date: Thu, 11 May 2000 09:07:43 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] URI's in SIP messages References: <200005081932.OAA06333@b04a45.exu.ericsson.se> <39173AAA.E5B25BC7@americasm01.nt.com> <3919E388.A317ECAC@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------AA68DC2E7F58AE2CE0596D11" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------AA68DC2E7F58AE2CE0596D11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan, I think I was trying to make the same point; perhaps I wasn't direct enough. I do think that most people, perhaps erroneously, equate URI to URI-reference with respect to BNF. And the one place that I know about that has something close to a complete SIP BNF: actually links URI (and Request-URI for that matter) to a rule called URI-reference but is defined as: URI-reference = ([ absoluteURI | relativeURI] [ "#" fragment]) | (sip-url) So I think some clarification in this area would be helpful. Rick Jonathan Rosenberg wrote: > Rick Workman wrote: > > > > > > > > Sean Olson wrote: > > > > > > The current SIP BNF allows the general form of URI (or > > > URI-reference?) to > > > > be used in the request line and various headers. Observations and > > > > questions: > > > > > > > > 1. A valid form of URI (RFC 2396)is the empty sequence since: > > > > > > > > URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] > > > > > > > > This would permit the request line and various headers (To, From, > > > > Contact. ..) without an address specification which doesn't seem > > > to make > > > > much sense. RFC 2396 specifies that the empty sequence URI refers > > > to the > > > > start of the current document; is there any corresponding > > > abstraction for > > > > SIP transcations? > > > > > > No. Please god no. Obviously RFC2396 specifies a much wider and more > > > abstract form > > > of URI than is commonly used in SIP. Not everything in 2396 is > > > appropriate for > > > every URI scheme. They are a set of guidelines that work more or > > > less for the most > > > common URI schemes in use today: http, ftp, telnet, mailto (with > > > some quirks), etc. > > > > > > > Be that as it may, they're guidelines which are now an integral part > > of the SIP BNF. > > Actually, this doesn't seem to be the case. The BNF for request URI, for > example, is never defined in RFC2543! It says in section 4.3 thats its > either a SIP URI or general URI. The BNF for addr-spec (used in To, > From, Contact) is defined as SIP-URL or URI, but I also never found the > BNF for URI. Even rfc2396 doesn't define "URI", but rather absoluteURI, > relativeURI or URI-reference. > > I believe what URI really means in the SIP context is absoluteURI. That > is, there must always be a scheme, followed by a colon. I believe this > eliminates many of the ambiguities people have been raising. I'm not a > big fan of relative URIs within HTTP itself (as opposed to within HTML, > where the browser computes the absolute URI and puts that in the HTTP > request); in general, I believe URIs sent on the wire should be globally > resolvable. HTTP ran into all sorts of problems, as I recall, since URIs > were not always absolute, and thus servers that supported many domains > got confused when they received things like GET index.html HTTP/1.0. > > > > > > > > > > > > > > > > > 2. The relative URI references a resource relative to a base URI > > > of a > > > > hierarchial scheme. So a similar question: is this a useful > > > concept for > > > > SIP sessions? > > > > > > > > > > The only contexts where I would think this might be useful would be > > > in > > > 1) The headers parameter of a SIP URI (for the From: and possibly > > > To: headers) > > > 2) A SIP "cookie" similar to an HTTP-cookie. This hasn't really been > > > investigated > > > much but would be interesting. > > > > > > In other words, I don't think it is generally useful in the usual > > > places in a SIP > > > message (To/From/Contact/Request-URI). But it is potentially useful > > > at the user interface > > > level or as part of some service logic. > > > > As part of a SIP message? I guess I can think of many examples where > > you want to map user friendly "addresses" to URI's in SIP messages, > > but that's out of scope for this discussion. > > I really don't see the use of relative URIs within SIP itself. > > > > > > > > > > > > > 3. Finally RFC 2396 states (my emphasis): > > > > "When a URI reference is used to perform a retrieval action on > > > the > > > > identified resource, the optional fragment identifier, > > > separated from > > > > the URI by a crosshatch ("#") character, consists of additional > > > > > > > reference information to be interpreted by the user agent after > > > the > > > > retrieval action has been successfully completed. As such, it > > > is not > > > > part of a URI, but is often used in conjunction with a URI." > > > > > > > > > > True, but this treated in very different ways by different web > > > browsers. Some > > > treat it as part of the URI, others use it for "post-processing". > > > It's not really used in a standard way for SIP, but as stated above > > > it really is up > > > to the UserAgent's interpretation. THIS IS A GOOD THING. > > > > I'm not arguing the merits of the URI syntax, just how it's used in > > SIP messages. > > Again, if we say that URI = absoluteURI, this problem goes away also. > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com --------------AA68DC2E7F58AE2CE0596D11 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan,

I think I was trying to make the same point; perhaps I wasn't direct enough. I do think that most people, perhaps erroneously, equate URI to URI-reference with respect to BNF. And the one place that I know about that has something close to a complete SIP BNF:

<http://www.cs.columbia.edu/~hgs/sip/SIPgrammar.html>

actually links URI (and Request-URI for that matter) to a rule called URI-reference but is defined as:

URI-reference = ([ absoluteURI | relativeURI] [ "#" fragment]) | (sip-url)

So I think some clarification in this area would be helpful.

Rick
 

Jonathan Rosenberg wrote:

Rick Workman wrote:
>
>
>
> Sean Olson wrote:
>
> > > The current SIP BNF allows the general form of URI (or
> > URI-reference?) to
> > > be used in the request line and various headers. Observations and
> > > questions:
> > >
> > > 1. A valid form of URI (RFC 2396)is the empty sequence since:
> > >
> > > URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
> > >
> > > This would permit the request line and various headers (To, From,
> > > Contact. ..) without an address specification which doesn't seem
> > to make
> > > much sense. RFC 2396 specifies that the empty sequence URI refers
> > to the
> > > start of the current document; is there any corresponding
> > abstraction for
> > > SIP transcations?
> >
> > No. Please god no. Obviously RFC2396 specifies a much wider and more
> > abstract form
> > of URI than is commonly used in SIP. Not everything in 2396 is
> > appropriate for
> > every URI scheme. They are a set of guidelines that work more or
> > less for the most
> > common URI schemes in use today: http, ftp, telnet, mailto (with
> > some quirks), etc.
> >
>
> Be that as it may, they're guidelines which are now an integral part
> of the SIP BNF.

Actually, this doesn't seem to be the case. The BNF for request URI, for
example, is never defined in RFC2543! It says in section 4.3 thats its
either a SIP URI or general URI. The BNF for addr-spec (used in To,
From, Contact) is defined as SIP-URL or URI, but I also never found the
BNF for URI. Even rfc2396 doesn't define "URI", but rather absoluteURI,
relativeURI or URI-reference.

I believe what URI really means in the SIP context is absoluteURI. That
is, there must always be a scheme, followed by a colon. I believe this
eliminates many of the ambiguities people have been raising. I'm not a
big fan of relative URIs within HTTP itself (as opposed to within HTML,
where the browser computes the absolute URI and puts that in the HTTP
request); in general, I believe URIs sent on the wire should be globally
resolvable. HTTP ran into all sorts of problems, as I recall, since URIs
were not always absolute, and thus servers that supported many domains
got confused when they received things like GET index.html HTTP/1.0.

>
> >
> >
> > >
> > > 2. The relative URI references a resource relative to a base URI
> > of a
> > > hierarchial scheme. So a similar question: is this a useful
> > concept for
> > > SIP sessions?
> > >
> >
> > The only contexts where I would think this might be useful would be
> > in
> > 1) The headers parameter of a SIP URI (for the From: and possibly
> > To: headers)
> > 2) A SIP "cookie" similar to an HTTP-cookie. This hasn't really been
> > investigated
> >    much but would be interesting.
> >
> > In other words, I don't think it is generally useful in the usual
> > places in a SIP
> > message (To/From/Contact/Request-URI). But it is potentially useful
> > at the user interface
> > level or as part of some service logic.
>
> As part of a SIP message? I guess I can think of many examples where
> you want to map user friendly "addresses" to URI's in SIP messages,
> but that's out of scope for this discussion.

I really don't see the use of relative URIs within SIP itself.

>
> >
> >
> > > 3. Finally RFC 2396 states (my emphasis):
> > >   "When a URI reference is used to perform a retrieval action on
> > the
> > >    identified resource, the optional fragment identifier,
> > separated from
> > >    the URI by a crosshatch ("#") character, consists of additional
> >
> > >    reference information to be interpreted by the user agent after
> > the
> > >    retrieval action has been successfully completed.  As such, it
> > is not
> > >    part of a URI, but is often used in conjunction with a URI."
> > >
> >
> > True, but this treated in very different ways by different web
> > browsers. Some
> > treat it as part of the URI, others use it for "post-processing".
> > It's not really used in a standard way for SIP, but as stated above
> > it really is up
> > to the UserAgent's interpretation. THIS IS A GOOD THING.
>
> I'm not arguing the merits of the URI syntax, just how it's used in
> SIP messages.

Again, if we say that URI = absoluteURI, this problem goes away also.

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

--------------AA68DC2E7F58AE2CE0596D11-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 10:51:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29459 for ; Thu, 11 May 2000 10:51:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DC92A44337; Thu, 11 May 2000 10:44:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 5AD3044336 for ; Thu, 11 May 2000 10:44:32 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA22333; Thu, 11 May 2000 15:49:02 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sip Mail List Date: Thu, 11 May 2000 13:26:38 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00051115451100.18078@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] Another grammar query - Call-ID Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi all, I have another grammar query, this time regarding the call-id. Call-ID is defined as (bis 6.12): callid = local-id @ host local-id = 1*uric Call-ID = ( Call-ID | i ) : callid and uric is defined as (bis Section 2 Figure 3): uric = reserved | unreserved | escaped reserved = ; | / | ? | : | @ | & | = | + | $ | , | [ | ] The problem here is with @. a valid local-id is a@b but that is also a valid local-id @ host so which is it? A parser is likely to claim that this is a local-id with no "@ host" value and declare it an invalid call-id. I think this is the same problem that occured with the definition of the Sip-URL and escaped characters in Section 2. Am i right in thinking that what was actually meant was: uric = unreserved | escaped where escaped allows the characters in the reserved set to be included? Thus any processing (equality checking etc...) of local-id is done on the un-escaped version but when transmitted in the message the escaped form must be used. If this is the case, I don't see any reason why any of the other characters in the reserved set need to be escaped. Quoting section 2: "Note that reserved characters have to be escaped and that the `set of characters reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding' [12]." Applying this to the call-id, only the @ changes the semantics of the Call-ID and so only the @ needs to be escaped. (Of course it is the case that any character in the local-id MAY be escaped and this MUST be handled by the parser). Am i correct about this? If so I think the whole `escaped' issue needs to be clarified somewhere (or have i just missed where it is clairified). regards gethin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 11:08:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29958 for ; Thu, 11 May 2000 11:08:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B63C94433D; Thu, 11 May 2000 11:02:02 -0400 (EDT) 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 A2D4144336 for ; Thu, 11 May 2000 11:01:59 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA08177; Thu, 11 May 2000 10:05:05 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA14736; Thu, 11 May 2000 10:05:02 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA08759; Thu, 11 May 2000 10:05:02 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id KAA25538; Thu, 11 May 2000 10:05:01 -0500 (CDT) Date: Thu, 11 May 2000 10:05:01 -0500 (CDT) Message-Id: <200005111505.KAA25538@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com, gethin@ubiquity.net Subject: Re: [SIP] Another grammar query - Call-ID X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > > Hi all, > > I have another grammar query, this time regarding the call-id. > > Call-ID is defined as (bis 6.12): > > callid = local-id @ host > local-id = 1*uric > Call-ID = ( Call-ID | i ) : callid > I may be wrong, but I seem to remember some agreement that Call-ID would become a token and would not necessarily need to take the form "local-id@host". But perhaps more importantly, I think its dangerous to start trying to parse the Call-ID and possibly derive information from it, such as the host. -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 11:17:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00346 for ; Thu, 11 May 2000 11:17:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 83BB744348; Thu, 11 May 2000 11:10:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id E8C7144346 for ; Thu, 11 May 2000 11:10:50 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA02526; Thu, 11 May 2000 16:15:04 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Another grammar query - Call-ID Date: Thu, 11 May 2000 16:04:52 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <200005111505.KAA25538@b04a45.exu.ericsson.se> In-Reply-To: <200005111505.KAA25538@b04a45.exu.ericsson.se> MIME-Version: 1.0 Message-Id: <00051116111201.18078@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Thu, 11 May 2000, Sean Olson wrote: > > > > Hi all, > > > > I have another grammar query, this time regarding the call-id. > > > > Call-ID is defined as (bis 6.12): > > > > callid = local-id @ host > > local-id = 1*uric > > Call-ID = ( Call-ID | i ) : callid > > > > I may be wrong, but I seem to remember some agreement that Call-ID would become > a token and would not necessarily need to take the form "local-id@host". Great, that makes things easier :) Can this be confirmed? > But perhaps more importantly, I think its dangerous to start trying to parse the Call-ID > and possibly derive information from it, such as the host. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 11:35:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00690 for ; Thu, 11 May 2000 11:35:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C51A4433D; Thu, 11 May 2000 11:28:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by lists.bell-labs.com (Postfix) with ESMTP id C05C444336 for ; Thu, 11 May 2000 11:28:44 -0400 (EDT) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel1.hp.com (Postfix) with ESMTP id 30179124; Thu, 11 May 2000 11:35:12 -0400 (EDT) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA26897; Thu, 11 May 2000 16:35:10 +0100 (BST) Message-ID: <391AD375.38464DB9@hplb.hpl.hp.com> Date: Thu, 11 May 2000 16:36:21 +0100 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Another grammar query - Call-ID References: <200005111505.KAA25538@b04a45.exu.ericsson.se> <00051116111201.18078@gethin> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gethin Liddell wrote: > > On Thu, 11 May 2000, Sean Olson wrote: > > > > > > Hi all, > > > > > > I have another grammar query, this time regarding the call-id. > > > > > > Call-ID is defined as (bis 6.12): > > > > > > callid = local-id @ host > > > local-id = 1*uric > > > Call-ID = ( Call-ID | i ) : callid > > > > > > > I may be wrong, but I seem to remember some agreement that Call-ID would become > > a token and would not necessarily need to take the form "local-id@host". Yes, except token didn't work because it doesn't include the '@' character. Basically, the field should be treated as an opaque, uninterpreted identifier, e.g. TEXT-UTF8-TRIM in the grammar. > > Great, that makes things easier :) > > Can this be confirmed? > > > But perhaps more importantly, I think its dangerous to start trying to parse the Call-ID > > and possibly derive information from it, such as the host. > -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 11:45:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00974 for ; Thu, 11 May 2000 11:45:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A86274434D; Thu, 11 May 2000 11:38:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by lists.bell-labs.com (Postfix) with ESMTP id 1958244346 for ; Thu, 11 May 2000 11:38:47 -0400 (EDT) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 043E0322; Thu, 11 May 2000 08:45:14 -0700 (PDT) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA27224; Thu, 11 May 2000 16:45:12 +0100 (BST) Message-ID: <391AD5CF.9CCAFBBA@hplb.hpl.hp.com> Date: Thu, 11 May 2000 16:46:23 +0100 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Expires header vs expires Contact param References: <391AAB8B.B29E7C36@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit My understanding of this is that the Expires header, if present, applies to all Contacts in a REGISTER request or response, UNLESS an expires parameter is present for that Contact, in which case the expires param takes precedence as it is more specific. Anders Neil Deason wrote: > > I think there could be scope for minor confusion over the intended use > of Expires header and Contact expires param in responses to REGISTER > requests. > > In the response to a REGISTER section 4.2.6 of the bis draft states that > an Expires header or expires Contact Param should be used to indicate > the time at which the registration will be dropped. To me this can be > taken to mean the two can be interchangeable and so presumably we are > are talking about the time a new Contact contained in the REGISTER will > be dropped. However, in section 6.22 it says that the Expires header is > used in the the response to a REGISTER to indicate the earliest expiry > time of all registrations. > > Furthermore is it correct to say that in the response to a REGISTER, > where active registrations already existed, the Expires header cannot be > used to indicate the time the new registration will be dropped and so an > expire Contact param has to be used. If so what is the point in a server > which adds expires Contact params to all active Contacts also adding an > Expires header to indicate the earliest expiry time of all > registrations. > > Cheers, > Neil. > -- > Ubiquity Software Corporation http://www.ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 12:48:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02753 for ; Thu, 11 May 2000 12:48:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D76AD44337; Thu, 11 May 2000 12:41:36 -0400 (EDT) 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 543F444336 for ; Thu, 11 May 2000 12:41:34 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 11 12:46:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8D45244344; Thu, 11 May 2000 12:33:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 6176944341 for ; Thu, 11 May 2000 12:33:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A380F52C4; Thu, 11 May 2000 12:33:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CCF6952AB for ; Thu, 11 May 2000 12:33:07 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 11 12:31:38 EDT 2000 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Thu May 11 12:31:36 EDT 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FUE00I01LWKA0@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 11 May 2000 16:31:32 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FUE00H3KLWKSE@firewall.mcit.com>; Thu, 11 May 2000 16:31:32 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FUE00D01LWH2W@pmismtp01.wcomnet.com>; Thu, 11 May 2000 16:31:31 +0000 (GMT) Received: from dwillispc8 ([166.35.227.170]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FUE00CBXLWBBY@pmismtp01.wcomnet.com>; Thu, 11 May 2000 16:31:24 +0000 (GMT) Date: Thu, 11 May 2000 11:30:54 -0500 From: Dean Willis In-reply-to: <3919E578.9FCE6061@dynamicsoft.com> To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Message-id: <002301bfbb66$47431460$aae323a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [SIP] Subscription and Notification Concepts (was RE: Two New Drafts) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Just as a reference point, there is an excellent paper on the Cambridge Event Architecture in the March 2000 "Computer". This included discussion of general issues around asynchronous event classification, roles, and use of certificates for identification and authorization in a role-membership model. While the implementation may be heavily IPRed (I believe Nortel underwote some of the work), I think some of the general concepts and nomenclature would be helpful to our discussion. I don't have the time at the moment to digest it fully, but it may be that some of our more studiouscompanions might wish to review this material and report on its applicability. -- Dean > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Wednesday, May 10, 2000 5:41 PM > To: Manoj Bhatia > Cc: archow@hss.hns.com; Adam B. Roach; sip@lists.research.bell-labs.com; > stlevy@cisco.com > Subject: [SIP] Re: Two New Drafts > > > > > Manoj Bhatia wrote: > > > > Hi Jonathan > > > > Can we at least draw some consensus on the 'Meesage Waiting > > Indication(MWI)' > > event in Voice mail context ? > > I think there is a clear need for subscription and notification events > for many things, including message waiting indication. The question is > how to structure this in the most general way. I really don't want a > specific and separate spec just for MWI, as it seems to narrow. > > > > > Further, in one of the threads on this list, Henning says that we must > > adopt > > drafts/discussion on PINT to decide on MWI. > > To me, what this means is that: > > 1. we use the SUBSCRIBE and NOTIFY methods > 2. the body is used to define the object being subscribed to > > > > > > Also, there is some concern that whether SUBSCRIBE - a new SIP method > > > > should be used for sending subscription requests or is REGISTER a good > > way of doing that ? > > Definitely not REGISTER. Its semantics are completely different. It > updates a binding, in a server, of the address in the To with the > addresses in the Contact. I don't see at all how this accomplishes MWI. > > > > > My concern is that very soon you may have interop problems with > > SUBSCRIBE/ > > REGISTER method being used by vendors in different ways . > > You should absolutely not be using REGISTER for this. > > > > > Is SUBSCRIBE/NOTIFY the de facto way for MWI implementation ? > > I think it is clearly the basis. The question, again, is how to do this > generally. > > Some of the questions in my mind are: > > 1. how do we handle addressing? I.e., what is the entity that is being > subscribed to, in the request URI, for mwi? Is it even a SIP URL? > > 2. What is the format of the content in the body for mwi? Is there a > format which is more generic than just mwi? > > 3. What is the format of the content in notifications? > > 4. security issues - how do you prevent attacks whereby I subscribe to > some events, and list someone else in the Contact, say, to receive the > notifications? > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 12:56:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02927 for ; Thu, 11 May 2000 12:56:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3B1CD44346; Thu, 11 May 2000 12:49:36 -0400 (EDT) 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 BF77344343 for ; Thu, 11 May 2000 12:49:33 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu May 11 12:54:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1B2BB44345; Thu, 11 May 2000 12:41:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E701844341 for ; Thu, 11 May 2000 12:41:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5A15452C4; Thu, 11 May 2000 12:41:11 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 93C9F52AB for ; Thu, 11 May 2000 12:41:08 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 11 12:40:42 EDT 2000 Received: from imr1.ericy.com ([208.237.135.240]) by dusty; Thu May 11 12:40:41 EDT 2000 Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA22605; Thu, 11 May 2000 11:39:04 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA00785; Thu, 11 May 2000 11:39:01 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA16265; Thu, 11 May 2000 11:39:00 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id LAA26040; Thu, 11 May 2000 11:39:00 -0500 (CDT) Date: Thu, 11 May 2000 11:39:00 -0500 (CDT) Message-Id: <200005111639.LAA26040@b04a45.exu.ericsson.se> To: sip@lists.research.bell-labs.com, pint@lists.bell-labs.com X-Sun-Charset: US-ASCII Subject: [SIP] Mailing list for SUBSCRIBE/NOTIFY Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I started an informal mailing list to hash out some of the details of the SUBSCRIBE/NOTIFY extension to SIP. You can find this at: http://www.egroups.com/group/sip-sub I don't intend to subvert the main SIP mailing list, this is just a place to hash out some ideas until the SIP working group decides to make this a work item. For a starting point, take a look at the following drafts: http://www.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-pip-00.txt and http://www.ietf.org/internet-drafts/draft-ietf-pint-protocol-04.txt -- Sean Olson Ericsson Inc. tel: +1-972-583-5472 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 13:26:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03721 for ; Thu, 11 May 2000 13:26:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B0B444434B; Thu, 11 May 2000 13:20:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id C0F2044336 for ; Thu, 11 May 2000 13:19:58 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id SAA15040; Thu, 11 May 2000 18:20:01 +0100 (BST) Message-ID: <391AEBC1.217CBE7E@ubiquity.net> Date: Thu, 11 May 2000 18:20:01 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Expires header vs expires Contact param References: <391AAB8B.B29E7C36@ubiquity.net> <391AD5CF.9CCAFBBA@hplb.hpl.hp.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > My understanding of this is that the Expires header, if present, applies > to all Contacts in a REGISTER request or response, UNLESS an expires > parameter is present for that Contact, in which case the expires param > takes precedence as it is more specific. Thanks. Looking again 6.13 of the bis draft does state that in a REGISTER 2xx response if a Contact entry does not have an optional expires param, the value of the Expires header is used. If neither mechanism is used, the expiration time specified in the request, explicitly or default, is used. Is this compatible with using the Expires header to indicate the earliest expiry time of all registrations (6.22). Imagine a user registers from a location supplying no expiry time. The server assumes 1 hour and returns a 2xx response which includes this new registration and another longstanding registration. Isn't it possible that the new Contact could contain no expires param and the Expires header be set to the duration of the long standing registration? Is there a reason why servers shouldn't be made to use the expires Contact param for every Contact? This would avoid the potential for any confusion and make the need for the Expires header to state the earliest expiry time of all registratations largely redundant. Cheers, Neil -- Ubiquity Software Corporation http://www.ubiquity.net > > I think there could be scope for minor confusion over the intended use > > of Expires header and Contact expires param in responses to REGISTER > > requests. > > > > In the response to a REGISTER section 4.2.6 of the bis draft states that > > an Expires header or expires Contact Param should be used to indicate > > the time at which the registration will be dropped. To me this can be > > taken to mean the two can be interchangeable and so presumably we are > > are talking about the time a new Contact contained in the REGISTER will > > be dropped. However, in section 6.22 it says that the Expires header is > > used in the the response to a REGISTER to indicate the earliest expiry > > time of all registrations. > > > > Furthermore is it correct to say that in the response to a REGISTER, > > where active registrations already existed, the Expires header cannot be > > used to indicate the time the new registration will be dropped and so an > > expire Contact param has to be used. If so what is the point in a server > > which adds expires Contact params to all active Contacts also adding an > > Expires header to indicate the earliest expiry time of all > > registrations. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 13:40:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04090 for ; Thu, 11 May 2000 13:40:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59DD344353; Thu, 11 May 2000 13:34:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 835D64433D for ; Thu, 11 May 2000 13:34:03 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA11802; Thu, 11 May 2000 13:36:35 -0400 (EDT) Message-ID: <391AEFA3.CBC4763@cisco.com> Date: Thu, 11 May 2000 13:36:35 -0400 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] Expires header vs expires Contact param References: <391AAB8B.B29E7C36@ubiquity.net> <391AD5CF.9CCAFBBA@hplb.hpl.hp.com> <391AEBC1.217CBE7E@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think the registrar should return the expires parameter in each Contact in the 200 OK, specifying the GMT time at which this registration/Contact will expire. The Expires header in the 200 OK would specify the earliest of these expiration time(s). Comments ?? Shail Neil Deason wrote: > Thanks. Looking again 6.13 of the bis draft does state that in a REGISTER 2xx > response if a Contact entry does not have an optional expires param, the value > of the Expires header is used. If neither mechanism is used, the expiration > time specified in the request, explicitly or default, is used. > > Is this compatible with using the Expires header to indicate the earliest > expiry time of all registrations (6.22). Imagine a user registers from a > location supplying no expiry time. The server assumes 1 hour and returns a 2xx > response which includes this new registration and another longstanding > registration. Isn't it possible that the new Contact could contain no expires > param and the Expires header be set to the duration of the long standing > registration? > > Is there a reason why servers shouldn't be made to use the expires Contact > param for every Contact? This would avoid the potential for any confusion and > make the need for the Expires header to state the earliest expiry time of all > registratations largely redundant. > > Cheers, > Neil > -- > Ubiquity Software Corporation http://www.ubiquity.net > > > > I think there could be scope for minor confusion over the intended use > > > of Expires header and Contact expires param in responses to REGISTER > > > requests. > > > > > > In the response to a REGISTER section 4.2.6 of the bis draft states that > > > an Expires header or expires Contact Param should be used to indicate > > > the time at which the registration will be dropped. To me this can be > > > taken to mean the two can be interchangeable and so presumably we are > > > are talking about the time a new Contact contained in the REGISTER will > > > be dropped. However, in section 6.22 it says that the Expires header is > > > used in the the response to a REGISTER to indicate the earliest expiry > > > time of all registrations. > > > > > > Furthermore is it correct to say that in the response to a REGISTER, > > > where active registrations already existed, the Expires header cannot be > > > used to indicate the time the new registration will be dropped and so an > > > expire Contact param has to be used. If so what is the point in a server > > > which adds expires Contact params to all active Contacts also adding an > > > Expires header to indicate the earliest expiry time of all > > > registrations. > > _______________________________________________ > 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 May 11 13:52:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04290 for ; Thu, 11 May 2000 13:52:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 792DC44359; Thu, 11 May 2000 13:45:35 -0400 (EDT) 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 07BB644339 for ; Thu, 11 May 2000 13:45:32 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu May 11 13:50:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 50E2944344; Thu, 11 May 2000 13:37:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 2A88D44341 for ; Thu, 11 May 2000 13:37:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 79EB852C4; Thu, 11 May 2000 13:37:10 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A0AC852B6 for ; Thu, 11 May 2000 13:37:07 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 11 13:35:55 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu May 11 13:35:54 EDT 2000 Received: from dynamicsoft.com (1Cust38.max1.par2.fra.da.uu.net [195.129.10.38]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA12410; Thu, 11 May 2000 13:37:09 -0400 (EDT) Message-ID: <391AF21F.E1EC5F2F@dynamicsoft.com> Date: Thu, 11 May 2000 13:47:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.research.bell-labs.com, pint@lists.bell-labs.com Subject: Re: [SIP] Mailing list for SUBSCRIBE/NOTIFY References: <200005111639.LAA26040@b04a45.exu.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Well, I had already created (and I think announced) an egroups list for it - sip-events@egroups.com. We definitely don't need 2. -Jonathan R. Sean Olson wrote: > > I started an informal mailing list to hash out some of the details of the > SUBSCRIBE/NOTIFY extension to SIP. You can find this at: > > http://www.egroups.com/group/sip-sub > > I don't intend to subvert the main SIP mailing list, this is just a place to hash > out some ideas until the SIP working group decides to make this a work item. > > For a starting point, take a look at the following drafts: > > http://www.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt > > http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-pip-00.txt > > and > > http://www.ietf.org/internet-drafts/draft-ietf-pint-protocol-04.txt > > -- > Sean Olson > Ericsson Inc. > tel: +1-972-583-5472 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 11 13:53:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04311 for ; Thu, 11 May 2000 13:53:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A9DF744339; Thu, 11 May 2000 13:46:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6080244356 for ; Thu, 11 May 2000 13:46:11 -0400 (EDT) Received: from dynamicsoft.com (1Cust38.max1.par2.fra.da.uu.net [195.129.10.38]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA12434; Thu, 11 May 2000 13:48:12 -0400 (EDT) Message-ID: <391AF4B6.AF873A8C@dynamicsoft.com> Date: Thu, 11 May 2000 13:58:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] Expires header vs expires Contact param References: <391AAB8B.B29E7C36@ubiquity.net> <391AD5CF.9CCAFBBA@hplb.hpl.hp.com> <391AEBC1.217CBE7E@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > Anders Kristensen wrote: > > > My understanding of this is that the Expires header, if present, applies > > to all Contacts in a REGISTER request or response, UNLESS an expires > > parameter is present for that Contact, in which case the expires param > > takes precedence as it is more specific. > > Thanks. Looking again 6.13 of the bis draft does state that in a REGISTER 2xx > response if a Contact entry does not have an optional expires param, the value > of the Expires header is used. If neither mechanism is used, the expiration > time specified in the request, explicitly or default, is used. > > Is this compatible with using the Expires header to indicate the earliest > expiry time of all registrations (6.22). Yes. The header has clear meaning. Its only confusing if you interpret it to mean the expiration time of all Contact headers, rather than the earliest expiry. Imagine a user registers from a > location supplying no expiry time. The server assumes 1 hour and returns a 2xx > response which includes this new registration and another longstanding > registration. Isn't it possible that the new Contact could contain no expires > param and the Expires header be set to the duration of the long standing > registration? Then the registrar screwed up. The expires parameter and Expires header have clear definitions in the response. In this example, the registrar set it wrong. > > Is there a reason why servers shouldn't be made to use the expires Contact > param for every Contact? This would avoid the potential for any confusion and > make the need for the Expires header to state the earliest expiry time of all > registratations largely redundant. I would definitely recommend using the expires parameters for every contact header. Its an implementation decision, though. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 11 13:55:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04354 for ; Thu, 11 May 2000 13:55:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E51144354; Thu, 11 May 2000 13:49:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4444644353 for ; Thu, 11 May 2000 13:49:16 -0400 (EDT) Received: from dynamicsoft.com (1Cust38.max1.par2.fra.da.uu.net [195.129.10.38]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA12542; Thu, 11 May 2000 13:56:54 -0400 (EDT) Message-ID: <391AF6C0.6C159A84@dynamicsoft.com> Date: Thu, 11 May 2000 14:06:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rick Workman Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] URI's in SIP messages References: <200005081932.OAA06333@b04a45.exu.ericsson.se> <39173AAA.E5B25BC7@americasm01.nt.com> <3919E388.A317ECAC@dynamicsoft.com> <391AB09F.917BD671@americasm01.nt.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rick Workman wrote: > > Jonathan, > > I think I was trying to make the same point; perhaps I wasn't direct > enough. I do think that most people, perhaps erroneously, equate URI > to URI-reference with respect to BNF. And the one place that I know > about that has something close to a complete SIP BNF: > > > > actually links URI (and Request-URI for that matter) to a rule called > URI-reference but is defined as: > > URI-reference = ([ absoluteURI | relativeURI] [ "#" fragment]) | > (sip-url) > > So I think some clarification in this area would be helpful. Right; I'm basically saying I believe this grammar to be wrong. URI should be absoluteURI. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 11 14:02:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04602 for ; Thu, 11 May 2000 14:02:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7D9844341; Thu, 11 May 2000 13:56:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 924E744338 for ; Thu, 11 May 2000 13:55:49 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA13649; Thu, 11 May 2000 14:01:16 -0400 (EDT) Message-ID: <391AF56C.4ABE3C88@cisco.com> Date: Thu, 11 May 2000 14:01:16 -0400 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Sip Mail List Subject: Re: [SIP] Another grammar query - Call-ID References: <00051115451100.18078@gethin> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I don't see any issue with this syntax. Do a reverse search on '@' sign in the Call-ID header value - anything preceeding it is the local-id and anything after it is the host. I don't think host names can have '@' sign. Gethin Liddell wrote: > > Hi all, > > I have another grammar query, this time regarding the call-id. > > Call-ID is defined as (bis 6.12): > > callid = local-id @ host > local-id = 1*uric > Call-ID = ( Call-ID | i ) : callid > > and uric is defined as (bis Section 2 Figure 3): > > uric = reserved | unreserved | escaped > reserved = ; | / | ? | : | @ | & | = | + | $ | , | [ | ] > > The problem here is with @. > > a valid local-id is > > a@b > > but that is also a valid > > local-id @ host > > so which is it? > A parser is likely to claim that this is a local-id with no "@ host" value and declare > it an invalid call-id. > > I think this is the same problem that occured with the definition of the Sip-URL and > escaped characters in Section 2. Am i right in thinking that what was actually meant > was: > > uric = unreserved | escaped > > where escaped allows the characters in the reserved set to be included? > > Thus any processing (equality checking etc...) of local-id is done on the un-escaped > version but when transmitted in the message the escaped form must be used. If this is > the case, I don't see any reason why any of the other characters in the reserved set > need to be escaped. > > Quoting section 2: > > "Note that reserved characters have to be escaped and that the `set of characters > reserved within any given URI component is defined by that component. In general, a > character is reserved if the semantics of the URI changes if the character is replaced > with its escaped US-ASCII encoding' [12]." > > Applying this to the call-id, only the @ changes the semantics of the Call-ID and so > only the @ needs to be escaped. (Of course it is the case that any character in the > local-id MAY be escaped and this MUST be handled by the parser). > > Am i correct about this? If so I think the whole `escaped' issue needs to be clarified > somewhere (or have i just missed where it is clairified). > > regards > > gethin > > _______________________________________________ > 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 May 11 14:09:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04775 for ; Thu, 11 May 2000 14:09:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9075844353; Thu, 11 May 2000 14:03:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 1799644336 for ; Thu, 11 May 2000 14:03:12 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id TAA03613; Thu, 11 May 2000 19:03:25 +0100 (BST) Message-ID: <391AF5ED.645FFF78@ubiquity.net> Date: Thu, 11 May 2000 19:03:25 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Anders Kristensen , sip@lists.bell-labs.com Subject: Re: [SIP] Expires header vs expires Contact param References: <391AAB8B.B29E7C36@ubiquity.net> <391AD5CF.9CCAFBBA@hplb.hpl.hp.com> <391AEBC1.217CBE7E@ubiquity.net> <391AF4B6.AF873A8C@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Neil Deason wrote: > > > > Anders Kristensen wrote: > > > > > My understanding of this is that the Expires header, if present, applies > > > to all Contacts in a REGISTER request or response, UNLESS an expires > > > parameter is present for that Contact, in which case the expires param > > > takes precedence as it is more specific. > > > > Thanks. Looking again 6.13 of the bis draft does state that in a REGISTER 2xx > > response if a Contact entry does not have an optional expires param, the value > > of the Expires header is used. If neither mechanism is used, the expiration > > time specified in the request, explicitly or default, is used. > > > > Is this compatible with using the Expires header to indicate the earliest > > expiry time of all registrations (6.22). > > Yes. The header has clear meaning. Its only confusing if you interpret > it to mean the expiration time of all Contact headers, rather than the > earliest expiry. Thanks Jonathan, this was the source of my confusion. What is the thinking behind setting the Expires header to the time when the first of a users active registration runs out. I had mistakenly thought it was the time they all ran out as this would be significant in that then the user wouldn't be registered anywhere. Cheers, Neil. -- Ubiquity Software Corporation http://www.ubiquity.net > > > Imagine a user registers from a > > location supplying no expiry time. The server assumes 1 hour and returns a 2xx > > response which includes this new registration and another longstanding > > registration. Isn't it possible that the new Contact could contain no expires > > param and the Expires header be set to the duration of the long standing > > registration? > > Then the registrar screwed up. The expires parameter and Expires header > have clear definitions in the response. In this example, the registrar > set it wrong. > > > > > Is there a reason why servers shouldn't be made to use the expires Contact > > param for every Contact? This would avoid the potential for any confusion and > > make the need for the Expires header to state the earliest expiry time of all > > registratations largely redundant. > > I would definitely recommend using the expires parameters for every > contact header. Its an implementation decision, though. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 May 11 14:32:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05564 for ; Thu, 11 May 2000 14:32:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B2F04433D; Thu, 11 May 2000 14:25:34 -0400 (EDT) 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 E4F2B44336 for ; Thu, 11 May 2000 14:25:31 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 11 14:30:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0CA9744344; Thu, 11 May 2000 14:17:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id CEB1244341 for ; Thu, 11 May 2000 14:17:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 55A8C52C4; Thu, 11 May 2000 14:17:09 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 66C5F52AB for ; Thu, 11 May 2000 14:17:06 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu May 11 14:15:20 EDT 2000 Received: from imr1.ericy.com ([208.237.135.240]) by dusty; Thu May 11 14:15:19 EDT 2000 Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id NAA04390; Thu, 11 May 2000 13:15:18 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA18738; Thu, 11 May 2000 13:15:15 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA21320; Thu, 11 May 2000 13:15:14 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA26167; Thu, 11 May 2000 13:15:13 -0500 (CDT) Date: Thu, 11 May 2000 13:15:13 -0500 (CDT) Message-Id: <200005111815.NAA26167@b04a45.exu.ericsson.se> To: sip@lists.research.bell-labs.com, pint@lists.bell-labs.com, eussean@exu.ericsson.se X-Sun-Charset: US-ASCII Subject: [SIP] Re: Mailing list for SUBSCRIBE/NOTIFY Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com My apologies for creating a duplicate list. I somehow missed Jonathon's announcement. I defer to Jonathan's list :) (http://www.egroups.com/group/sip-events) Thanks Jonathan. -- Sean Olson Ericsson Inc. tel: +1-972-583-5472 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 18:22:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09155 for ; Thu, 11 May 2000 18:22:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B08AA44337; Thu, 11 May 2000 18:15:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id 23F8B44336 for ; Thu, 11 May 2000 18:15:30 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04502; Thu, 11 May 2000 16:21:56 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA16769; Thu, 11 May 2000 15:21:52 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA22239; Thu, 11 May 2000 15:21:51 -0700 (PDT) Message-Id: <200005112221.PAA22239@nasnfs.eng.sun.com> Date: Thu, 11 May 2000 15:24:45 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide To: sip@lists.bell-labs.com, jdrosen@dynamicsoft.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: rTY8HHY3OBcMGH6MBpzadw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id SAA09155 Couple of comments. >3. AUTHENTICATION (end-to-end) >============================== >We have the following potential authentication requirements: >- Called party id >- Calling party id >- Who we thought we were calling > This doesn't say anything about a client authenticating a proxy, but that seems to be implied by the subsequent discussion. >Dean Willis and Robert Sparks objected that you need app-level security >when you don’t >have transitivity of trust, and there are applications where you do not >have transitivity >of trust. For example, consider a call where you involve multiple >providers for that call >(multi-proxy authenticate). Basically, it’s not enough to have either >end-to-end or >hop-by-hop security; you also need to have end-to-intermediate security. > >This was a different model than had been worked on for the majority of >the meeting >however no one argued against the validity of it. Since it contradicts >some of the >earlier assumptions and decisions made during the meeting, each of these >will have to be >revisited. > I`m not exactly sure what is meant by "application level security" here. Does "application" mean "application built on top of SIP" or does it mean "SIP as an application protocol? Certainly in the case of cellular, it will be the case that the proxy will be changing. When the mobile terminal roams outside of it's cellular provider's domain, the new proxy needs to be authenticated with the mobile terminal, and vice versa. This roaming can happen either statically or dynamically, i.e. statically when the mobile terminal comes up in a foreign domain, or dynamically, when a call is in progress and the mobile roams into an area where its provider does not have coverage but a provider with a roaming agreement does. jak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 11 19:22:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10758 for ; Thu, 11 May 2000 19:22:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DCA7344340; Thu, 11 May 2000 19:15:34 -0400 (EDT) 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 605A244339 for ; Thu, 11 May 2000 19:15:31 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 11 19:20:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 40B2C44344; Thu, 11 May 2000 19:07:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1A5A444341 for ; Thu, 11 May 2000 19:07:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D59C852C8; Thu, 11 May 2000 19:07:11 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 773F952AB for ; Thu, 11 May 2000 19:07:07 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu May 11 19:07:04 EDT 2000 Received: from dnspri.npac.com ([208.143.33.66]) by dusty; Thu May 11 19:07:02 EDT 2000 Received: by dnspri.npac.com; id SAA01046; Thu, 11 May 2000 18:06:55 -0500 (CDT) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma000962; Thu, 11 May 00 18:05:57 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Thu, 11 May 2000 18:05:41 -0500 Message-ID: From: James Yu To: jdrosen@dynamicsoft.com Cc: "'Vance Shipley'" , John Mainwaring , Mark Foster , iptel@lists.research.bell-labs.com, sip@lists.research.bell-labs.com Subject: RE: [SIP] Re: TRIP Date: Thu, 11 May 2000 18:05:07 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com It is fine with me. James > -----Original Message----- > From: S_S_Dinesh/India/IBM@au1.ibm.com > [mailto:S_S_Dinesh/India/IBM@au1.ibm.com] > Sent: Monday, May 08, 2000 4:40 AM > To: James Yu > Cc: 'Vance Shipley'; John Mainwaring; Mark Foster; > iptel@lists.research.bell-labs.com; sip@lists.research.bell-labs.com > Subject: [SIP] Re: TRIP > > > > > We've discussed this on the list. Several folks pointed out that > European systems support overlap, and it was decided that it was not > reasonable to mandate the originating gateway to do digit > collection to > convert this to en-bloc, although it could be optionally done. > > -Jonathan R. > > James Yu wrote: > > > > Vance, > > > > Thanks for the explanation. > > > > The key questions now are whether overlap signaling (e.g., Feature > Group-D > > over Multi-Frequency facility) is still used somewhere and > if used where > the > > digit collection/enbloc signaling is performed in the existing SCN. > > > > If overlap signaling is still used (someone please confirm this and > indicate > > where it is still used) and a call is to be routed from the > originating > SCN > > to the Internet, I guess that the originating GW > (SCN-Internet)probably > has > > to perform the digit collection/enbloc signaling function > so that overlap > > signaling does not propagate further into the Internet and/or the > > destination GW/SCN. Otherwise, some entities in the Internet must > perform > > that function. > > > > James > > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > > > > > _______________________________________________ > 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 May 11 19:40:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11039 for ; Thu, 11 May 2000 19:40:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 234FF44351; Thu, 11 May 2000 19:33:36 -0400 (EDT) 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 3E2FF44343 for ; Thu, 11 May 2000 19:33:30 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 11 19:38:22 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3773144344; Thu, 11 May 2000 19:25:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 0C9BF44341 for ; Thu, 11 May 2000 19:25:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A7BE952C8; Thu, 11 May 2000 19:25:12 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E18C152B6 for ; Thu, 11 May 2000 19:25:08 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 11 19:23:44 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu May 11 19:23:43 EDT 2000 Received: from dynamicsoft.com (1Cust38.max1.par2.fra.da.uu.net [195.129.10.38]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA13935; Thu, 11 May 2000 19:24:53 -0400 (EDT) Message-ID: <391B439D.B82587B4@dynamicsoft.com> Date: Thu, 11 May 2000 19:34:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu Cc: "'Vance Shipley'" , John Mainwaring , Mark Foster , iptel@lists.research.bell-labs.com, sip@lists.research.bell-labs.com Subject: Re: [SIP] Re: TRIP References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit FYI, folks, please ignore all email you saw from S_S_Dinesh/India/IBM@aul.ibm.com. This mail is all resends of old messages back to the list based on misconfiguration of a machine within IBM. -Jonathan R. James Yu wrote: > > It is fine with me. > > James > > > -----Original Message----- > > From: S_S_Dinesh/India/IBM@au1.ibm.com > > [mailto:S_S_Dinesh/India/IBM@au1.ibm.com] > > Sent: Monday, May 08, 2000 4:40 AM > > To: James Yu > > Cc: 'Vance Shipley'; John Mainwaring; Mark Foster; > > iptel@lists.research.bell-labs.com; sip@lists.research.bell-labs.com > > Subject: [SIP] Re: TRIP > > > > > > > > > > We've discussed this on the list. Several folks pointed out that > > European systems support overlap, and it was decided that it was not > > reasonable to mandate the originating gateway to do digit > > collection to > > convert this to en-bloc, although it could be optionally done. > > > > -Jonathan R. > > > > James Yu wrote: > > > > > > Vance, > > > > > > Thanks for the explanation. > > > > > > The key questions now are whether overlap signaling (e.g., Feature > > Group-D > > > over Multi-Frequency facility) is still used somewhere and > > if used where > > the > > > digit collection/enbloc signaling is performed in the existing SCN. > > > > > > If overlap signaling is still used (someone please confirm this and > > indicate > > > where it is still used) and a call is to be routed from the > > originating > > SCN > > > to the Internet, I guess that the originating GW > > (SCN-Internet)probably > > has > > > to perform the digit collection/enbloc signaling function > > so that overlap > > > signaling does not propagate further into the Internet and/or the > > > destination GW/SCN. Otherwise, some entities in the Internet must > > perform > > > that function. > > > > > > James > > > > > -- > > Jonathan D. Rosenberg 200 Executive Drive > > Chief Scientist Suite 120 > > dynamicsoft West Orange, NJ 07052 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 11 20:39:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11569 for ; Thu, 11 May 2000 20:39:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0C7B4433F; Thu, 11 May 2000 20:32:57 -0400 (EDT) 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 8600E44339 for ; Thu, 11 May 2000 20:32:50 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Thu, 11 May 2000 14:27:15 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KXJMR3Y2; Thu, 11 May 2000 15:23:45 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K365N6P0; Thu, 11 May 2000 15:23:44 -0400 Message-ID: <391B099D.34ABEE3F@americasm01.nt.com> Date: Thu, 11 May 2000 15:27:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] 2543 bis: Section H.1 URI Syntax/header syntax References: <3912C921.D7E42893@americasm01.nt.com> <200005051417.KAA19665@ind.cs.columbia.edu> <3912E862.2E967219@cs.columbia.edu> <200005051647.MAA21169@ind.cs.columbia.edu> <39130BEC.7273EAFE@americasm01.nt.com> <39135330.99B49770@cs.columbia.edu> <3919ACC0.5D9BAB71@americasm01.nt.com> Content-Type: multipart/alternative; boundary="------------AC8570DA29B18D948607FC59" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------AC8570DA29B18D948607FC59 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Didn't get this quite right. RFC 2732 (IPv6 Literal Addresses in URL's) updates RFC 2396 to include "[" and "]" in the URL reserved set. Corrected ABNF is: headers = "?" header *("&" header) header = hname "=" hvalue hname = 1*(hname_char) hvalue = *(hvalue_char) hname_char = alphanum | "-" | "." | "!" | "*" | "_" | "+" | "'" | "~" hvalue_char = hvreserved | unreserved | escaped hvreserved = ";" | "/" | "?" | ":" | "@" | "=" | "+" | "$" | "[" | "]" Rick Workman Nortel Networks Ottawa > > In an attempt to get some closure on the SIP-URL header BNF, how > about: > > headers = "?" header *("&" header) > header = hname "=" hvalue > hname = 1*(hname_char) > hvalue = *(hvalue_char) > > hname_char = alphanum | "-" | "." | "!" | "*" | "_" | "+" | "'" | "~" > > hvalue_char = hvreserved | unreserved | escaped > hvreserved = ";" | "/" | "?" | ":" | "@" | "=" | "+" |"$" > > > Notes: > 1. This isn't strictly backward compatible but I can't see any > practical issues. (Same as proposed change to other-param?) > 2. hname_char set is a subset of token (to be consistent with > "field-name") which doesn't include "%" (URI "delims") or "`" (URI > "unwise"). > 3. hvreserved is a subset of the current reserved rule eliminating > "&", "," as per earlier discussion, and "[" and "]" (both URI > "unwise"). > 4. Scanning the current header definitions, at least the following > must be escaped: > - any required LWS, e.g., for token separation or in rfc1123 dates > - double quotes in quoted strings > - "\" in quoted-pair (comments and quoted-strings) > - "%" and "`" in tokens > - "<" and ">" in name-addrs > - "&" in any embedded SIP-URL headers > - "," in # lists > - any illegal characters in TEXT-UTF8 > - any others? > 5. Multi-byte UTF-8 characters will be represent by a 2*escaped , > i.e., the UTF-8 character CA98 will escape to %CA%98. (I think this > was the intent of Jonathan Lennox's previous proposal.) > > > Also, I'd like to see the text concerning reserved characters and > escaping clarified. If the BNF can be tightened up to the point where > the allowable characters for any SIP-URL component have been clearly > defined, then, by definition, any other characters must be escaped. > Calling these other characters reserved confuses them with those in > the "reserved" rule in the URI spec (and the current SIP RFC). Am I > missing something? > > > Rick Workman > Nortel Networks > Ottawa --------------AC8570DA29B18D948607FC59 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Didn't get this quite right. RFC 2732 (IPv6 Literal Addresses in URL's) updates RFC 2396 to include "[" and "]" in the URL reserved set. Corrected ABNF is:

headers     = "?" header *("&" header)
header      = hname "=" hvalue
hname       = 1*(hname_char)
hvalue      = *(hvalue_char)

hname_char  = alphanum | "-" | "." | "!" | "*" | "_" | "+" | "'" | "~"

hvalue_char = hvreserved | unreserved | escaped
hvreserved  = ";" | "/" | "?" | ":" | "@" | "=" | "+" | "$" | "[" | "]"
 
 

Rick Workman
Nortel Networks
Ottawa
 

 
In an attempt to get some closure on the SIP-URL header BNF, how about:

headers     = "?" header *("&" header)
header      = hname "=" hvalue
hname       = 1*(hname_char)
hvalue      = *(hvalue_char)

hname_char  = alphanum | "-" | "." | "!" | "*" | "_" | "+" | "'" | "~"

hvalue_char = hvreserved | unreserved | escaped
hvreserved  = ";" | "/" | "?" | ":" | "@" | "=" | "+" |"$"
 

Notes:
1. This isn't strictly backward compatible but I can't see any practical issues. (Same as proposed change to other-param?)
2. hname_char set is a subset of token (to be consistent with "field-name") which doesn't include "%" (URI "delims") or "`" (URI "unwise").
3. hvreserved is a subset of the current reserved rule eliminating "&", "," as per earlier discussion, and "[" and "]" (both URI "unwise").
4. Scanning the current header definitions, at least the following must be escaped:
   - any required LWS, e.g., for token separation or in rfc1123 dates
   - double quotes in quoted strings
   - "\" in quoted-pair (comments and quoted-strings)
   - "%" and "`" in tokens
   - "<" and ">" in name-addrs
   - "&" in any embedded SIP-URL headers
   - "," in # lists
   - any illegal characters in TEXT-UTF8
   - any others?
5. Multi-byte UTF-8 characters will be represent by a 2*escaped , i.e., the UTF-8 character CA98 will escape to %CA%98. (I think this was the intent of Jonathan Lennox's previous proposal.)
 

Also, I'd like to see the text concerning reserved characters and escaping clarified. If the BNF can be tightened up to the point where the allowable characters for any SIP-URL component have been clearly defined, then, by definition, any other characters must be escaped. Calling these other characters reserved confuses them with those in the "reserved" rule in the URI spec (and the current SIP RFC). Am I missing something?
 

Rick Workman
Nortel Networks
Ottawa

--------------AC8570DA29B18D948607FC59-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 12 05:48:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29914 for ; Fri, 12 May 2000 05:48:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8DC0C44338; Fri, 12 May 2000 05:41:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id 64ABD44336 for ; Fri, 12 May 2000 05:41:52 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA30591 for ; Fri, 12 May 2000 10:39:13 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA09238 for ; Fri, 12 May 2000 11:48:09 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id LAA28166 for ; Fri, 12 May 2000 11:48:23 +0200 (MET DST) Received: from young.dinsunnet (young [188.9.34.36]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id LAA24135; Fri, 12 May 2000 11:48:20 +0200 (MET DST) Received: from ms.alcatel.fr by young.dinsunnet (8.9.1b+Sun/SMI-SVR4) id LAA21499; Fri, 12 May 2000 11:48:22 +0200 (MET DST) Message-ID: <391BD365.1ADCE8E9@ms.alcatel.fr> Date: Fri, 12 May 2000 11:48:22 +0200 From: Francois-Xavier Guitton X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: SIP Subject: [SIP] Use of warning header in an INVITE message Content-Type: multipart/alternative; boundary="------------E7561AD6287056485BD51C4C" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------E7561AD6287056485BD51C4C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, RFC 2543 specifies warning header as optional in the INVITE method. But the chapter describing Warning (6.41 Warning p 72) only details the usage of that header in case of a response. So my question is: what is the purpose of the warning header in an INVITE message ? Best regards, -- Francois-Xavier Guitton (SWD/ULC) mailto:Francois-Xavier.Guitton@ms.alcatel.fr Tel: +33 (0)1 69 63 47 52 Fax: +33 (0)1 69 63 17 89 --------------E7561AD6287056485BD51C4C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

RFC 2543 specifies warning header as optional in the INVITE method. But the chapter describing Warning (6.41 Warning p 72) only details the usage of that header in case of a response. So my question is: what is the purpose of the warning header in an INVITE message ?

Best regards, 

-- 
Francois-Xavier Guitton (SWD/ULC)
mailto:Francois-Xavier.Guitton@ms.alcatel.fr      
Tel: +33 (0)1 69 63 47 52                    
Fax: +33 (0)1 69 63 17 89
  --------------E7561AD6287056485BD51C4C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 12 09:36:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02121 for ; Fri, 12 May 2000 09:36:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD5DD44339; Fri, 12 May 2000 09:29:41 -0400 (EDT) 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 BFE8144336 for ; Fri, 12 May 2000 09:29:38 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id IAA04905; Fri, 12 May 2000 08:36:15 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id IAA07898; Fri, 12 May 2000 08:36:13 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA07408; Fri, 12 May 2000 08:36:12 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id IAA28229; Fri, 12 May 2000 08:36:12 -0500 (CDT) Date: Fri, 12 May 2000 08:36:12 -0500 (CDT) Message-Id: <200005121336.IAA28229@b04a45.exu.ericsson.se> To: Francois-Xavier.Guitton@ms.alcatel.fr Subject: Re: [SIP] Use of warning header in an INVITE message Cc: sip@lists.bell-labs.com X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Hello, > > RFC 2543 specifies warning header as optional in the INVITE method. But > the chapter describing Warning (6.41 Warning p 72) only details the > usage of that header in case of a response. So my question is: what is > the purpose of the warning header in an INVITE message ? > > Best regards, > > -- > Francois-Xavier Guitton (SWD/ULC) > mailto:Francois-Xavier.Guitton@ms.alcatel.fr > Tel: +33 (0)1 69 63 47 52 > Fax: +33 (0)1 69 63 17 89 I was unable to find any place in the bis draft that stated Warning: was optional for the INVITE request. The table on page 36, section 6.1 indicates that the Warning: header is optional for INVITE responses (the lowercase r in the "where" column). -- Sean Olson Ericsson Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 12 19:59:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18444 for ; Fri, 12 May 2000 19:59:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6692744338; Fri, 12 May 2000 19:52:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C085744336 for ; Fri, 12 May 2000 19:52:16 -0400 (EDT) Received: from dynamicsoft.com (1Cust41.max1.par2.fra.da.uu.net [195.129.10.41]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA17130; Fri, 12 May 2000 20:00:02 -0400 (EDT) Message-ID: <391C9D5E.BFED0AAA@dynamicsoft.com> Date: Fri, 12 May 2000 20:10:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit James Kempf wrote: > > Couple of comments. > > >3. AUTHENTICATION (end-to-end) > >============================== > >We have the following potential authentication requirements: > >- Called party id > >- Calling party id > >- Who we thought we were calling > > > > This doesn't say anything about a client authenticating a proxy, > but that seems to be implied by the subsequent discussion. e2e authentication is not about client authenticating a proxy, its about clients authenticating clients. hBh authentication involves client authentication of proxies and vice a versa. > > >Dean Willis and Robert Sparks objected that you need app-level security > >when you don’t > >have transitivity of trust, and there are applications where you do not > >have transitivity > >of trust. For example, consider a call where you involve multiple > >providers for that call > >(multi-proxy authenticate). Basically, it’s not enough to have either > >end-to-end or > >hop-by-hop security; you also need to have end-to-intermediate security. > > > >This was a different model than had been worked on for the majority of > >the meeting > >however no one argued against the validity of it. Since it contradicts > >some of the > >earlier assumptions and decisions made during the meeting, each of these > >will have to be > >revisited. > > > > I`m not exactly sure what is meant by "application level security" here. > Does "application" mean "application built on top of SIP" or does > it mean "SIP as an application protocol? The latter. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 12 20:36:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19257 for ; Fri, 12 May 2000 20:36:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6FA2544342; Fri, 12 May 2000 20:30:02 -0400 (EDT) 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 934154433C for ; Fri, 12 May 2000 20:29:59 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA17269; Fri, 12 May 2000 17:36:46 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA10892; Fri, 12 May 2000 17:36:39 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14620.41878.763300.49818@thomasm-u1.cisco.com> Date: Fri, 12 May 2000 17:36:38 -0700 (PDT) To: James Kempf Cc: sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <200005112221.PAA22239@nasnfs.eng.sun.com> References: <200005112221.PAA22239@nasnfs.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf writes: > I`m not exactly sure what is meant by "application level security" here. > Does "application" mean "application built on top of SIP" or does > it mean "SIP as an application protocol? The latter. > Certainly in the case of cellular, it will be the case that the > proxy will be changing. When the mobile terminal roams outside > of it's cellular provider's domain, the new proxy needs to be authenticated > with the mobile terminal, and vice versa. That sort of pre-supposes that the proxy the handset contacts when it's roamed isn't its home proxy. I'm not sure I see why that wouldn't still be the case. I hope people aren't getting buffaloed into some garden walls kind of mentality where the service provider gets to keep their stranglehold on services. If you ask me, the only thing I want the cellular service provider to provide me is bits on the air (ie, access, QoS). Where I get routing information, etc, should be my choice. Settling the bits on the air could have a component which involves SIP (ala DQoS), but it shouldn't force me to get services through SlamAir if don't want to. Not that that has anything to do with SIP security. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat May 13 05:19:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06870 for ; Sat, 13 May 2000 05:19:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 52D0244354; Sat, 13 May 2000 05:12:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out1.prserv.net [32.97.166.31]) by lists.bell-labs.com (Postfix) with ESMTP id 250C344351 for ; Sat, 13 May 2000 05:12:13 -0400 (EDT) Received: from cs.columbia.edu ([139.92.232.23]) by prserv.net (out1) with SMTP id <2000051309183025201q04pve>; Sat, 13 May 2000 09:18:31 +0000 Message-ID: <391D1635.C81EDDD3@cs.columbia.edu> Date: Sat, 13 May 2000 04:45:41 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <391A0713.5A7AC492@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit > A number of people participated in the SIP Security Task Force meeting Must have been a really secure meeting if the identity of the participants is secret :-) > Jonathan Rosenberg opened the discussion by suggesting that: > - SIP encryption (not authentication) should be deprecated, because: I strongly disagree with this. SIP encryption serves a number of useful purposes. It hides information, for example, about Contact, Subject, Organization, Retry-After, media types, media IP addresses and meeting times (in SDP), SDP k= keys, etc. All of these are irrelevant for proxy routing behavior, but highly sensitive. > o It doesn’t work with NAT and firewalls That's a risk you take. I refuse to dumb down protocols for everybody just because some people are behind firewalls and NATs. There are lots of protocols or features that you can't use behind a firewall or NAT. > o It assumes you know the public key of the party you are calling, > which is not a good > assumption. It works in many cases. In other cases it can be made to work, e.g., via indirection. > o It only really hides the body (and again that doesn’t work well due > to the above). See above. > > Initial discussion of these points led to the decision that it should > still be possible > to support end-to-end encryption as there may be some uses for it. Agreed. > > A problem with the current end-to-end encryption scheme is, that it > relies on knowing the > public key of the other party. One way of solving that is to return a > public key in the > response and simply do a re-INVITE then. However, it was agreed that we > should not do > that, as we effectively end up duplicating IKE, or something similar. > > Dave Oran suggested that end-to-end information that needs encryption > should simply go in > the body (don’t encrypt headers). We could use multipart for this, or > simply allow for a > single body to be encrypted and define an error code to be returned if > the proxy needs to > see the body (e.g. if SDP is encrypted and message traverses a > firewall). The group > decided to accept this mechanism. The error code will only support > coarse granularity, > i.e., if multiple bodies are encrypted, you will not be told which one > is needed in > clear, just a general error saying “body not understood”. I had originally (many years ago) suggested a similar mechanism, assuming I understand your proposal correctly, namely to have a body type "SIP message", which is encrypted. A decision was made not to do this (I'm afraid I no longer remember the reason; might have been message size concerns or processing logic). If you only want to encrypt SDP, I disagree, for the reasons stated above. If you want to do both and use the "SIP message" body mechanism, I'm not against this, but this does entail a significant protocol change, without changing any of the other problems. > > Additional discussion on encryption of headers ensued. Contact is an > example of header > that can be usefully encrypted (end-to-end), but in general, there > doesn’t seem to be a > whole lot of use for this (generally, if the information is relevant it > can’t be > encrypted). Only want the registrar to see the Contact, not any of the > intermediate > proxies. Again, I disagree, see above. > 3. AUTHENTICATION (end-to-end) > ============================== > 3.1 Hop-by-hop Authentication > ============================= > We want to have at least one mechanism specified in the SIP > specification. Why? This gets into endless arguments as to which is better. > > It was decided that we should have the following hop-by-hop security > mechanisms: > - Server to server: IPSec using ESP transport, > - Client to server: IPSec using ESP transport (not clear ESP transport > was agreed to) Disagree. For practical reasons, TLS is much easier to deploy (keying, available libraries, available infrastructure to obtain keys, etc.). Are there any technical reasons to force somebody to implement IPsec? > > 4. Miscellaneous > ================ > > 4.1 Areas needing further work > ============================== > - Challenge-response doesn’t work with forking (but addresses replay) as > only one 401 > will get back to the caller. This can be solved, at the cost of increased proxy complexity, by having the proxy gather all challenges from all branches and return them in the 401 response, similar to multi-proxy authentication. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat May 13 05:23:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06869 for ; Sat, 13 May 2000 05:19:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B52C74433C; Sat, 13 May 2000 05:11:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out1.prserv.net [32.97.166.31]) by lists.bell-labs.com (Postfix) with ESMTP id 3136544336 for ; Sat, 13 May 2000 05:11:43 -0400 (EDT) Received: from cs.columbia.edu ([139.92.232.23]) by prserv.net (out1) with SMTP id <2000051309180025201q04ple>; Sat, 13 May 2000 09:18:02 +0000 Message-ID: <391D05CC.32060D9C@cs.columbia.edu> Date: Sat, 13 May 2000 03:35:40 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Rick Workman , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] URI's in SIP messages References: <200005081932.OAA06333@b04a45.exu.ericsson.se> <39173AAA.E5B25BC7@americasm01.nt.com> <3919E388.A317ECAC@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > I believe what URI really means in the SIP context is absoluteURI. That > is, there must always be a scheme, followed by a colon. I believe this > eliminates many of the ambiguities people have been raising. I'm not a > big fan of relative URIs within HTTP itself (as opposed to within HTML, > where the browser computes the absolute URI and puts that in the HTTP > request); in general, I believe URIs sent on the wire should be globally > resolvable. HTTP ran into all sorts of problems, as I recall, since URIs > were not always absolute, and thus servers that supported many domains > got confused when they received things like GET index.html HTTP/1.0. There are two kinds of relative URLs: omitting the host part (which is what got HTTP/1.0 into trouble) and relative URLs that are relative to the current file system location (as in ../../foo.html). The first is not helpful, the second not applicable. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat May 13 12:22:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09613 for ; Sat, 13 May 2000 12:22:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA82B4434B; Sat, 13 May 2000 12:15:05 -0400 (EDT) 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 D4A0C4433E for ; Sat, 13 May 2000 12:15:02 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA24736; Sat, 13 May 2000 09:21:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11103; Sat, 13 May 2000 09:21:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14621.33050.682399.735419@thomasm-u1.cisco.com> Date: Sat, 13 May 2000 09:21:46 -0700 (PDT) To: Henning Schulzrinne Cc: Jonathan Rosenberg , sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <391D1635.C81EDDD3@cs.columbia.edu> References: <391A0713.5A7AC492@dynamicsoft.com> <391D1635.C81EDDD3@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/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > > o It assumes you know the public key of the party you are calling, > > which is not a good > > assumption. > > It works in many cases. In other cases it can be made to work, e.g., via > indirection. Just as a general note -- again -- any dependence on public key signatures/encryption on a per message basis will not scale. They may work in toy systems, but when you start talking about systems which must do 10-100's of transactions per second, they simply do not scale: it is simply beyond the state of the art by several orders of magnitude. I have no particular qualms about having the ability to use public key operations as a quick and dirty (and stateless) way to do crypto, but we *must* have the ability to take anything which used a public key operation before and have a symmetric key analog for it, and SIP's must support it as a basic mechanism. Obviously, symmetric key operation begs the question of key distribution, of which there may be many choices -- I personally think that kerberos covers the most bases in a scalable fashion, though not all. However, even if the the key distribution is done by Palantir, we have to have a way to do this. I'm somewhat ignorant of PGP, so forgive me if this already part of it. All public key signatures and encryptions still rely on symmetric key operations: signatures do a SHA-1 HMAC over the message and then encrypts the resulting hash with their private key. Encryption cons's up a key and runs 3DES over the message. It then encrypts the key itself with the sendee's public key. In both cases, there is a base level symmetric key operation which is common. This should be abstracted such that either symmetric key or public key operations are a choice which is discernible at the receiver. As I read 2543 right now, however, there seems to be a base level assumption that it is *always* done through public key. If PGP doesn't allow for symmetric key only, then the entire mechanism is incomplete and needs to be fixed. Even if PGP doesn't make that assumption, it would be very nice in 2543bis to actually show that you don't need to always use public key operations as the current text is highly misleading. > > We want to have at least one mechanism specified in the SIP > > specification. > > Why? This gets into endless arguments as to which is better. There were no endless arguments in MEGACO about this, which argued about everything endlessly. > > It was decided that we should have the following hop-by-hop security > > mechanisms: > > - Server to server: IPSec using ESP transport, > > - Client to server: IPSec using ESP transport (not clear ESP transport > > was agreed to) > > Disagree. For practical reasons, TLS is much easier to deploy (keying, > available libraries, available infrastructure to obtain keys, etc.). Are > there any technical reasons to force somebody to implement IPsec? Yes: there is no such thing as TLS over UDP. Even if there is some experimental UDP based version, it negates the advantages you list above. Also: which OS's don't have IPsec these days? Beyond that, TLS is the worst of all possible worlds: if I'm a programmer, I either want to have fine control on what portions of the stream I diddle at the added complexity of understanding how the API and functionality works, or I want to be completely ignorant of what goes on at a lower layer. TLS, however, requires that I learn the API *and* gives me none of the benefits of fine control. IPsec at least has the know-nothing property; the application can remain utterly ignorant. Considering the pathetic state of security right now, anything that puts a requirement for a program to touch *anything* is tantamount to saying that it won't happen any time soon. IPsec at least gives users a third party frob to compensate for application inadequacy; TLS does not. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun May 14 03:43:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05554 for ; Sun, 14 May 2000 03:43:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61ED54433E; Sun, 14 May 2000 03:36:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out4.prserv.net [32.97.166.34]) by lists.bell-labs.com (Postfix) with ESMTP id B4A5844336 for ; Sun, 14 May 2000 03:36:04 -0400 (EDT) Received: from cs.columbia.edu ([139.92.232.79]) by prserv.net (out4) with SMTP id <2000051407425023900lhe7de>; Sun, 14 May 2000 07:42:52 +0000 Message-ID: <391DD714.BA3EFEFB@cs.columbia.edu> Date: Sat, 13 May 2000 18:28:36 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Jonathan Rosenberg , sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <391A0713.5A7AC492@dynamicsoft.com> <391D1635.C81EDDD3@cs.columbia.edu> <14621.33050.682399.735419@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Henning Schulzrinne writes: > > > o It assumes you know the public key of the party you are calling, > > > which is not a good > > > assumption. > > > > It works in many cases. In other cases it can be made to work, e.g., via > > indirection. > > Just as a general note -- again -- any > dependence on public key signatures/encryption > on a per message basis will not scale. They > may work in toy systems, but when you start They work just fine (modulo the PKI problem) in anything *but* large-scale PSTN gateways. Presumably, gateways are a transient (albeit important) problem. > talking about systems which must do 10-100's > of transactions per second, they simply do > not scale: it is simply beyond the state of > the art by several orders of magnitude. > > I have no particular qualms about having the > ability to use public key operations as a > quick and dirty (and stateless) way to do > crypto, but we *must* have the ability to > take anything which used a public key operation > before and have a symmetric key analog for it, > and SIP's must support it as a basic mechanism. > > Obviously, symmetric key operation begs the > question of key distribution, of which there > may be many choices -- I personally think that > kerberos covers the most bases in a scalable > fashion, though not all. However, even if the > the key distribution is done by Palantir, we > have to have a way to do this. I have yet to see a scalable, inter-domain Kerberos system. What makes you believe that this is easier than regular public key? Most intelligent-endsystem (as opposed to PSTN gateway) calls will be essentially random and sparse in time, with intervals between calling the same system longer than the ticket lifetime, so that rekeying will be needed for each call. I can't imagine that this scales any better. > > I'm somewhat ignorant of PGP, so forgive me > if this already part of it. All public key > signatures and encryptions still rely on > symmetric key operations: signatures do a > SHA-1 HMAC over the message and then encrypts > the resulting hash with their private key. Encryption > cons's up a key and runs 3DES over the message. > It then encrypts the key itself with the > sendee's public key. > > In both cases, there is a base level symmetric > key operation which is common. This should be > abstracted such that either symmetric key or > public key operations are a choice which is > discernible at the receiver. As I read 2543 > right now, however, there seems to be a base > level assumption that it is *always* done > through public key. If PGP doesn't allow > for symmetric key only, then the entire > mechanism is incomplete and needs to be > fixed. Even if PGP doesn't make that > assumption, it would be very nice in > 2543bis to actually show that you don't need > to always use public key operations as the > current text is highly misleading. Again, except in the case of high-volume signaling trunks between gateways, interarrival times for calls between the same source-destination pair may well exceed customary ticket lifetimes. If we do have high-volume signaling trunks, we have existing resaonably efficinet mechanisms (IPsec, TLS) to handle this. I'm really reluctant to cook up a new mechanism until we know that the existing ones cannot do the trick. > There were no endless arguments in MEGACO about > this, which argued about everything endlessly. What's your concrete proposal? We'll see what arguments we get (or not...). > Yes: there is no such thing as TLS over UDP. For high-volume signaling trunks where key exchanges and operations matters, TCP is probably the more appropriate solution. > Even if there is some experimental UDP based > version, it negates the advantages you list > above. Also: which OS's don't have IPsec these > days? Windows 98 and Windows NT come to mind, at least out of the box. From all that I heard, most of the IPsec versions do not interoperate across OS or implementations. I believe there was even a report on installing IPsec on this list which struck me as basically requiring deep IPsec understanding to make anything work. Again: I have no problem with IPsec. I do have a problem with not supporting TLS. > > Beyond that, TLS is the worst of all possible > worlds: if I'm a programmer, I either want to > have fine control on what portions of the > stream I diddle at the added complexity of > understanding how the API and functionality > works, or I want to be completely ignorant of > what goes on at a lower layer. > > TLS, however, requires that I learn the API > *and* gives me none of the benefits of fine > control. IPsec at least has the know-nothing > property; the application can remain utterly > ignorant. Considering the pathetic state of > security right now, anything that puts a > requirement for a program to touch *anything* > is tantamount to saying that it won't happen > any time soon. IPsec at least gives users > a third party frob to compensate for > application inadequacy; TLS does not. How come that millions of web servers and other applications actually use TLS, on a daily basis? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun May 14 04:42:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06383 for ; Sun, 14 May 2000 04:42:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E60DB44352; Sun, 14 May 2000 04:35:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id 44A5644336 for ; Sun, 14 May 2000 04:35:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA02933; Sun, 14 May 2000 02:41:57 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA03301; Sat, 13 May 2000 19:19:19 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id TAA19786; Sat, 13 May 2000 19:19:16 -0700 (PDT) Message-Id: <200005140219.TAA19786@nasnfs.eng.sun.com> Date: Sat, 13 May 2000 19:22:12 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide To: James.Kempf@Eng.Sun.COM, mat@cisco.com Cc: sip@lists.bell-labs.com, jdrosen@dynamicsoft.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pH0IwtkUVCJQfBz3B2a0Aw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > > Certainly in the case of cellular, it will be the case that the > > proxy will be changing. When the mobile terminal roams outside > > of it's cellular provider's domain, the new proxy needs to be authenticated > > with the mobile terminal, and vice versa. > > That sort of pre-supposes that the proxy the > handset contacts when it's roamed isn't its > home proxy. I'm not sure I see why that > wouldn't still be the case. I hope people > aren't getting buffaloed into some garden > walls kind of mentality where the service > provider gets to keep their stranglehold on > services. > It's not the case because if I have my cellular account with a provider in California and I travel to Australia, I don't want to have to go all the way back to the SIP proxy with my provider in California to have to make a call. jak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun May 14 18:43:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12073 for ; Sun, 14 May 2000 18:43:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88C5244500; Sun, 14 May 2000 18:28:27 -0400 (EDT) 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 E216D44663 for ; Sun, 14 May 2000 16:23:36 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA00798; Sun, 14 May 2000 13:30:37 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA24845; Sun, 14 May 2000 13:30:30 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14623.3302.169458.272648@thomasm-u1.cisco.com> Date: Sun, 14 May 2000 13:30:30 -0700 (PDT) To: Henning Schulzrinne Cc: Michael Thomas , Jonathan Rosenberg , sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <391DD714.BA3EFEFB@cs.columbia.edu> References: <391A0713.5A7AC492@dynamicsoft.com> <391D1635.C81EDDD3@cs.columbia.edu> <14621.33050.682399.735419@thomasm-u1.cisco.com> <391DD714.BA3EFEFB@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/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > Just as a general note -- again -- any > > dependence on public key signatures/encryption > > on a per message basis will not scale. They > > may work in toy systems, but when you start > > They work just fine (modulo the PKI problem) in anything *but* > large-scale PSTN gateways. Presumably, gateways are a transient (albeit > important) problem. Um, no. Proxies which need to scale to 10's or 100's of thousands of users have the same problem. With current state of art, you could not build a proxy that big which requires public key operations. Low end gateways (25Mhz class) take hundreds of milliseconds -- I've heard going on a second -- to do one public operation. That is directly in the path of post dial delay. I don't see how you can handwave those issues away as unimportant. Large scale SIP deployments are hopefully going to do better than the PSTN -- and the rest of the Internet -- on security, but it certainly will not and can not happen if the bar is set too high. Also: it's telling that you brush the PKI problem aside as a detail. There's a reason why there's no such thing as a large scale PKI after 20 years of having the base technology: they're incredibly hard -- maybe insurmountably hard -- things to build. > I have yet to see a scalable, inter-domain Kerberos system. What makes > you believe that this is easier than regular public key? Well, for one it allows you to vastly scale down the reliance on public key infrastructure to a set of potentially high-touch machines (the KDC). Are you familiar with PKCROSS? Besides, you can do quite a lot with Kerberos without ever even getting into the cross realm tar pit. > Most intelligent-endsystem (as opposed to PSTN gateway) calls will be > essentially random and sparse in time, with intervals between calling > the same system longer than the ticket lifetime, so that rekeying will > be needed for each call. Well, there are more things than PSTN gateways which have scaling problems. IVR maze machines, conference bridges, proxies, etc, etc, will have identical scaling concerns. Kerberos tickets can also have a long lifetime -- days, weeks even. While it's questionable whether my IP phone at home would want to to have a service ticket for the end to end call, it's unquestionable that it would be a benefit to use Kerberos to key up the SA between the UA and its first hop proxy. *One* *call* would be enough to amortize the cost. > I can't imagine that this scales any better. The only thing you can say is that Kerberos degenerates into public key case in pathological situations. That's not a very strong starting point. > Again, except in the case of high-volume signaling trunks between > gateways, interarrival times for calls between the same > source-destination pair may well exceed customary ticket lifetimes. End to end is not the only consideration. In fact, it's the least interesting because I might just as well ship the end to end SIP keying material through in the initial INVITE as plain text if the destination is in the same trust domain as the KDC. >If > we do have high-volume signaling trunks, we have existing resaonably > efficinet mechanisms (IPsec, TLS) to handle this. I hope that you're not thinking that IPsec with IKE to do end to end keying would be viable between trunking gateways and high fan out UA's. TLS would be no better. > I'm really reluctant > to cook up a new mechanism until we know that the existing ones cannot > do the trick. Kerberos is a new mechanism? I guess if you consider the late 80's "new". SIP, and maybe HTTP, are conspicuous in their lack of a Kerberos mechanism. You can even use Kerberos to key RSVP integrity objects. And I don't know how much more you need to "know" here: I work for a manufacturer of a lot of the components that would be needed in a large scale SIP system. I know that it cannot be built now as specified, and I'm doubtful that it can be built any time soon. I do know, however, that a relatively simple and well understood piece of technology can make the entire problem moot. It seems like a no-brainer to me. Also as a point of reference: I think that SIP should recommend IPsec as the base hop by hop security mechanism. I don't think it needs to say anything about which key distribution protocol is recommended though. I have my opinions, but the spec doesn't need to reflect them. > What's your concrete proposal? We'll see what arguments we get (or > not...). The full protocol is being worked on as we speak. You can also look at the security spec on packetcable.com to get an idea of how you can do Kerberized IPsec for SIP. It's currently spec'd for MGCP, but the transported protocol is actually irrelevant. > > Yes: there is no such thing as TLS over UDP. > > For high-volume signaling trunks where key exchanges and operations > matters, TCP is probably the more appropriate solution. That's highly arguable; I'm sure the SCTP folks might have thought or two about that, and as far as I can tell, they have the full support of their AD's. > Windows 98 and Windows NT come to mind, at > least out of the box. Win2k and presumably (?) that other Windows market churner will have it. And you can always do bump in the stack and bump in the wire implementations of IPsec. > From > all that I heard, most of the IPsec versions do not interoperate across > OS or implementations. The problem isn't IPsec usually, the problem is with IKE. > Again: I have no problem with IPsec. I do have a problem with not > supporting TLS. But TLS doesn't address one quite legitimate and useful operational mode of SIP: UDP with ALF. That's quite a shortcoming. If we recommend any hop by hop security, it at the very least needs to work with all operational modes of SIP. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun May 14 23:18:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15749 for ; Sun, 14 May 2000 23:18:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D8F644583; Sun, 14 May 2000 18:12:13 -0400 (EDT) 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 52CFD4444F for ; Sun, 14 May 2000 16:29:56 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01421; Sun, 14 May 2000 13:36:57 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA24848; Sun, 14 May 2000 13:36:50 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14623.3681.981585.472974@thomasm-u1.cisco.com> Date: Sun, 14 May 2000 13:36:49 -0700 (PDT) To: James Kempf Cc: mat@cisco.com, sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <200005140219.TAA19786@nasnfs.eng.sun.com> References: <200005140219.TAA19786@nasnfs.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf writes: > > That sort of pre-supposes that the proxy the > > handset contacts when it's roamed isn't its > > home proxy. I'm not sure I see why that > > wouldn't still be the case. I hope people > > aren't getting buffaloed into some garden > > walls kind of mentality where the service > > provider gets to keep their stranglehold on > > services. > > > > It's not the case because if I have my cellular account with a provider > in California and I travel to Australia, I don't want to have to > go all the way back to the SIP proxy with my provider in California > to have to make a call. Why? Seriously. SIP is not a soft realtime protocol like, say, MGCP where you need tight timing tolerances. I can think of a myriad of reasons why my SIP cell phone doesn't want the local provider to be anything but a bits in the air transporter. I trust my SIP services to the service provider with whom I contract; I don't don't want slammer.au to have anything to do with delivering my services other than what base level physics requires. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 05:50:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00110 for ; Mon, 15 May 2000 05:50:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D49244336; Mon, 15 May 2000 05:43:06 -0400 (EDT) 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 BA22644351 for ; Mon, 15 May 2000 05:43:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 15 05:48:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5F9AA44341; Mon, 15 May 2000 05:35:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1032B44345 for ; Mon, 15 May 2000 05:35:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1818C52B6; Mon, 15 May 2000 05:35:21 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C16A552C4 for ; Mon, 15 May 2000 05:35:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 15 05:34:29 EDT 2000 Received: from paris.mds.local ([24.162.228.27]) by dusty; Mon May 15 05:34:28 EDT 2000 Received: from paulejpc (system@geneva.mds.local [192.168.1.2]) by paris.mds.local (8.8.7/8.8.7) with SMTP id FAA17630; Mon, 15 May 2000 05:34:24 -0400 Message-ID: <005f01bfbe50$f931e100$7f01a8c0@cisco.com> From: "Paul E. Jones" To: , , References: Date: Mon, 15 May 2000 05:35:50 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01BFBE2F.6DC04240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] Re: [IPTEL] RE: TRIP for gateway registrations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_005C_01BFBE2F.6DC04240 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable While it is true that RAS is not used to register a large number of = addresses, that will not be true in the future. H.323v4 supports two = mechanisms to allow MCUs or GWs to register large numbers of addresses = and address ranges. Paul ----- Original Message -----=20 From: S_S_Dinesh/India/IBM@au1.ibm.com=20 To: sip@lists.research.bell-labs.com ; = iptel@lists.research.bell-labs.com=20 Sent: Monday, May 08, 2000 4:40 AM Subject: [IPTEL] RE: TRIP for gateway registrations I would point out that H.323 RAS messages are not normally used to register a range of phone numbers for gateways as it is quite impractical, especially for gateways handling a large number of phone numbers, and when keep-alive messages are used. While some implementations uses tricks such as registering "dialling prefixes" to map to telephone number, it is not the intent of prefixes which are supposed to be used for special services. Normally, a gateway registers an alias with its gatekeeper and the = binding between the alias and the range of phone numbers handled by the gateway is "manually" configured in the gatekeeper, as described in the draft. I would think that TRIP could automate this process. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, March 09, 2000 11:33 PM > To: sip@lists.research.bell-labs.com; > iptel@lists.research.bell-labs.com > Subject: TRIP for gateway registrations > > > Folks, > > Every once in a while, the question comes up of why SIP > REGISTER is not > the right vehicle for allowing gateways to register phone > prefixes with > a proxy. I believe TRIP is far better for this purpose. As it > turns out, > a small subset of TRIP is needed to solve this problem, and yet its > still interoperable with full blown TRIP. Hussein Salama and I have > written an I-D that discusses this. Until it appears in the = archives, > you can pick up a copy at: > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > ------=_NextPart_000_005C_01BFBE2F.6DC04240 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
While it is true that RAS is not used to = register a large=20 number of addresses, that will not be true in the future.  H.323v4 = supports=20 two mechanisms to allow MCUs or GWs to register large numbers of = addresses and=20 address ranges.
 
Paul
----- Original Message -----
From:=20 S_S_Dinesh/India/IBM@au1.ibm.com= =20
To: sip@lists.research.bell-labs.com= ;=20 iptel@lists.research.bell-labs= .com=20
Sent: Monday, May 08, 2000 4:40 = AM
Subject: [IPTEL] RE: TRIP for = gateway=20 registrations



I would point out that H.323 RAS messages are = not=20 normally
used to register a range of phone numbers for gateways as = it
is=20 quite impractical, especially for gateways handling a large
number = of phone=20 numbers, and when keep-alive messages are used.

While some=20 implementations uses tricks such as registering
"dialling prefixes" = to map=20 to telephone number, it is not the
intent of prefixes which are = supposed to=20 be used for special services.

Normally, a gateway registers an = alias=20 with its gatekeeper and the binding
between the alias and the range = of=20 phone numbers handled by the
gateway is "manually" configured in = the=20 gatekeeper, as described
in the draft. I would think that TRIP = could=20 automate this process.

> -----Original Message-----
> = From:=20 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: = Thursday,=20 March 09, 2000 11:33 PM
> To: = sip@lists.research.bell-labs.com;
>=20 iptel@lists.research.bell-labs.com
> Subject: TRIP for gateway=20 registrations
>
>
> Folks,
>
> Every = once in a=20 while, the question comes up of why SIP
> REGISTER is = not
> the=20 right vehicle for allowing gateways to register phone
> prefixes = with
> a proxy. I believe TRIP is far better for this purpose. = As=20 it
> turns out,
> a small subset of TRIP is needed to = solve this=20 problem, and yet its
> still interoperable with full blown TRIP. = Hussein=20 Salama and I have
> written an I-D that discusses this. Until it = appears=20 in the archives,
> you can pick up a copy at:
>
>=20 = http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt
>= ;
>=20 Thanks,
> Jonathan R.
> --
> Jonathan D.=20 = Rosenberg          &nbs= p;           =20 200 Executive Drive
> Chief=20 = Scientist          &nbs= p;            = ;     =20 Suite 120
>=20 = dynamicsoft          &n= bsp;           &nb= sp;         =20 West Orange, NJ 07052
>=20 = jdrosen@dynamicsoft.com        &n= bsp;           =20 FAX:   (732) 741-4778
>=20 = http://www.cs.columbia.edu/~jdrosen      &n= bsp; =20 PHONE: (732) 741-7244
>=20 http://www.dynamicsoft.com
>
>
= ------=_NextPart_000_005C_01BFBE2F.6DC04240-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 08:07:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02059 for ; Mon, 15 May 2000 08:07:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E49C44351; Mon, 15 May 2000 08:00:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dns.ikv.de (unknown [193.158.64.250]) by lists.bell-labs.com (Postfix) with ESMTP id 5AF0344338; Mon, 15 May 2000 08:00:14 -0400 (EDT) Received: from heartofgold by dns.ikv.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id OAA31738; Mon, 15 May 2000 14:07:13 +0200 From: magedanz@ikv.de Reply-To: To: , , , , Date: Mon, 15 May 2000 14:07:21 +0200 Message-ID: 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 Importance: Normal Subject: [SIP] Final IN/IP Convergence CFP Reminder Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ladies and Gentlemen! Sorry in case you receive multiple copies of this emmail, which means your are very active ;-) Computer Networks Journal plans to publish in February 2001 a special issue on "Voice / Data Integration - A Snapshot of Intelligent Network and Interent Convergence". Guest editors: T. Magedanz (IKV++) and M. Smirnov (GMD FOKUS) Deadline for submission is June 5th, 2000!!! Maybe a good candidate for disseminating your results! For more infos look at: http://www.fokus.gmd.de/events/IN-Internet/ Best regards, Thomas Magedanz (magedanz@ikv.de) IKV++ GmbH, Bernburger Str. 24-25, D-10963 Berlin, Germany _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 08:24:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02300 for ; Mon, 15 May 2000 08:24:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1BB4B44362; Mon, 15 May 2000 08:16:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from email.aon.at (WS01SP29.highway.telekom.at [195.3.96.118]) by lists.bell-labs.com (Postfix) with ESMTP id 39AE24433E for ; Mon, 15 May 2000 08:16:56 -0400 (EDT) Received: from mwelser (N009P029.dipool.highway.telekom.at [195.3.65.29]) by email.aon.at (8.9.3/8.9.3) with SMTP id OAA317134 for ; Mon, 15 May 2000 14:23:54 +0200 Reply-To: From: "Michael Welser" To: "sip" Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Mon, 15 May 2000 14:24:13 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal In-Reply-To: <391D1635.C81EDDD3@cs.columbia.edu> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit > > o It doesn’t work with NAT and firewalls > > That's a risk you take. I refuse to dumb down protocols for everybody > just because some people are behind firewalls and NATs. There are lots > of protocols or features that you can't use behind a firewall or NAT. This opinion (attitude?) leads eventually to the discussions last heard in foglamps. I do not like NATs. But NATs are here, and they are reality for more than just "some people" (most of which do not even have a say about this) and they will be with us for quite some while. I refuse to smarten up protocols for everybody (thereby cutting off potential users from potential services) just because some people are NOT behind firewalls and NATs. There are some protocols or features that you can use behind a firewall or a NAT (otherwise the Internet wouldn't be what it is now). Michael Welser ------------------------------------------------------------ mailto:mwelser@highway.telekom.at Telekom Austria AG tel: +43 (1) 79711 1622 Abt RS fax: +43 (1) 79711 1608 Arsenal Objekt 22 http://www.telekom.at Postfach 111 http://www.aon.at A-1103 Wien _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 12:37:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06881 for ; Mon, 15 May 2000 12:37:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3CBB44338; Mon, 15 May 2000 12:29:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 87DFD44336 for ; Mon, 15 May 2000 12:29:47 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id SAA21250 for ; Mon, 15 May 2000 18:35:32 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id SAA27089 for ; Mon, 15 May 2000 18:34:17 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id SAA19110 for ; Mon, 15 May 2000 18:34:35 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA554; Mon, 15 May 2000 18:44:25 +0200 Message-ID: <392019ED.A97587BF@italtel.it> Date: Mon, 15 May 2000 17:38:22 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: James Kempf , sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> Content-Type: multipart/alternative; boundary="------------55383782A551F64459ED073B" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------55383782A551F64459ED073B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Certainly in the case of cellular, it will be the case that the > > proxy will be changing. When the mobile terminal roams outside > > of it's cellular provider's domain, the new proxy needs to be authenticated > > with the mobile terminal, and vice versa. > > That sort of pre-supposes that the proxy the > handset contacts when it's roamed isn't its > home proxy. I'm not sure I see why that > wouldn't still be the case. the current assumption is to have a "proxy" in the visited domain (it might be something more than a pure proxy). There are many reasons behind this choice (I might even be unaware of many others...). Just three examples: * possible optimizations (e.g.: signalling for a basic call to an Australian fixed network number from an Italian mobile roaming to Australia could be processed locally, without any "tromboning") * some people claim the "proxy" should also perform some kind of admission control for the calls. The proxy in the home domain has no information on the visited domain * the PNO who runs the visited network might desire to have some kind of knowledge on what is going on in his network, from a call control point of view Giuseppe ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- --------------55383782A551F64459ED073B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Thomas wrote:
 > Certainly in the case of cellular, it will be the case that the
 > proxy will be changing. When the mobile terminal roams outside
 > of it's cellular provider's domain, the new proxy needs to be authenticated
 > with the mobile terminal, and vice versa.

   That sort of pre-supposes that the proxy the
   handset contacts when it's roamed isn't its
   home proxy. I'm not sure I see why that
   wouldn't still be the case.

the current assumption is to have a "proxy" in the visited domain (it might be something more than a pure proxy).

There are many reasons behind this choice (I might even be unaware of many others...). Just three examples:

  • possible optimizations (e.g.: signalling for a basic call to an Australian fixed network number from an Italian mobile roaming to Australia could be processed locally, without any "tromboning")
  • some people claim the "proxy" should also perform some kind of admission control for the calls. The proxy in the home domain has no information on the visited domain
  • the PNO who runs the visited network might desire to have some kind of knowledge on what is going on in his network, from a call control point of view
Giuseppe

----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------
  --------------55383782A551F64459ED073B-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 13:44:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07751 for ; Mon, 15 May 2000 13:44:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C7CC4433E; Mon, 15 May 2000 13:37:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail02.rapidsite.net (mail02.rapidsite.net [207.158.192.68]) by lists.bell-labs.com (Postfix) with SMTP id 97F1944336 for ; Mon, 15 May 2000 13:37:16 -0400 (EDT) Received: from www.adventnetworks.com (207.158.252.140) by mail02.rapidsite.net (RS ver 1.0.55s) with SMTP id 02776198; Mon, 15 May 2000 13:41:31 -0400 (EDT) Reply-To: From: "Robert Johnson" To: , "'sip'" Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Mon, 15 May 2000 12:42:18 -0500 Message-ID: <001801bfbe94$eab32730$e501a8c0@rjohnson> 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.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Loop-Detect: 1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit >> > o It doesn’t work with NAT and firewalls >> >> That's a risk you take. I refuse to dumb down protocols for everybody >> just because some people are behind firewalls and NATs. There are lots >> of protocols or features that you can't use behind a firewall or NAT. > >This opinion (attitude?) leads eventually to the discussions last heard >in foglamps. > >I do not like NATs. But NATs are here, and they are reality for more >than just "some people" (most of which do not even have a say about >this) and they will be with us for quite some while. > >I refuse to smarten up protocols for everybody (thereby cutting off >potential users from potential services) just because some people are >NOT behind firewalls and NATs. There are some protocols or features that >you can use behind a firewall or a NAT (otherwise the Internet wouldn't >be what it is now). If we do not interwork with NATs, SIP will not fly. Most commercial Internet subscribers today pass through a NAT, whether they know it or not. However, deprecating SIP encryption forces implementers into incompatible product and network configurations, which is also a limiter to the growth of SIP. Like most enterprise H.323 implementations, most SIP implementations will operate completely within the enterprise domain, going outside through a proxy that is positioned to avoid the NAT/FW issue entirely. This, along with other arguments, leads me to think that deprecating SIP encryption is not necessarily the wisest move. Robert Johnson Director of Network Architecture Advent Networks (512) 397-4914 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 May 15 14:21:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08236 for ; Mon, 15 May 2000 14:21:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 641264436E; Mon, 15 May 2000 14:14:21 -0400 (EDT) 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 1DA4844336 for ; Mon, 15 May 2000 14:13:46 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 15 May 2000 13:08:20 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 May 2000 13:07:44 -0500 Message-ID: From: "Glenn Morrow" To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: sip Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Mon, 15 May 2000 13:07:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBE98.76901A08" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFBE98.76901A08 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Henning Schulzrinne [SMTP:hgs@cs.columbia.edu] > Sent: Saturday, May 13, 2000 3:46 AM > To: Jonathan Rosenberg > Cc: sip > Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide > > > A number of people participated in the SIP Security Task Force meeting > > Must have been a really secure meeting if the identity of the > participants is secret :-) > > > Jonathan Rosenberg opened the discussion by suggesting that: > > - SIP encryption (not authentication) should be deprecated, because: > > I strongly disagree with this. SIP encryption serves a number of useful > purposes. It hides information, for example, about Contact, Subject, > Organization, Retry-After, media types, media IP addresses and meeting > times (in SDP), SDP k= keys, etc. All of these are irrelevant for proxy > routing behavior, but highly sensitive. > I agree with the disagreement. > > o It doesn't work with NAT and firewalls > > That's a risk you take. I refuse to dumb down protocols for everybody > just because some people are behind firewalls and NATs. There are lots > of protocols or features that you can't use behind a firewall or NAT. > One could consider a SIP proxy as an ALG and a firewall element, could one not? If you agree with this then it does work for NAT and firewalls. I really sick of people using "NAT" as a logical fallacy in their arguments. Perhaps if we bury our heads in the sand long enough they will go away. > > o It assumes you know the public key of the party you are calling, > > which is not a good > > assumption. > > It works in many cases. In other cases it can be made to work, e.g., via > indirection. > Yep > > o It only really hides the body (and again that doesn't work well due > > to the above). > > See above. > > > > > Initial discussion of these points led to the decision that it should > > still be possible > > to support end-to-end encryption as there may be some uses for it. > > Agreed. > > > > > A problem with the current end-to-end encryption scheme is, that it > > relies on knowing the > > public key of the other party. One way of solving that is to return a > > public key in the > > response and simply do a re-INVITE then. However, it was agreed that we > > should not do > > that, as we effectively end up duplicating IKE, or something similar. > > > > Dave Oran suggested that end-to-end information that needs encryption > > should simply go in > > the body (don't encrypt headers). We could use multipart for this, or > > simply allow for a > > single body to be encrypted and define an error code to be returned if > > the proxy needs to > > see the body (e.g. if SDP is encrypted and message traverses a > > firewall). The group > > decided to accept this mechanism. The error code will only support > > coarse granularity, > > i.e., if multiple bodies are encrypted, you will not be told which one > > is needed in > > clear, just a general error saying "body not understood". > > I had originally (many years ago) suggested a similar mechanism, > assuming I understand your proposal correctly, namely to have a body > type "SIP message", which is encrypted. A decision was made not to do > this (I'm afraid I no longer remember the reason; might have been > message size concerns or processing logic). If you only want to encrypt > SDP, I disagree, for the reasons stated above. If you want to do both > and use the "SIP message" body mechanism, I'm not against this, but this > does entail a significant protocol change, without changing any of the > other problems. > > > > > Additional discussion on encryption of headers ensued. Contact is an > > example of header > > that can be usefully encrypted (end-to-end), but in general, there > > doesn't seem to be a > > whole lot of use for this (generally, if the information is relevant it > > can't be > > encrypted). Only want the registrar to see the Contact, not any of the > > intermediate > > proxies. > > Again, I disagree, see above. > I see a plethora of valuable uses for separate encryption process for the Contact and many other headers. Especially when there are hierarchies or network ownership boundaries between UAs, proxies, registrars, ALGs, etc.. > > 3. AUTHENTICATION (end-to-end) > > ============================== > > > 3.1 Hop-by-hop Authentication > > ============================= > > > We want to have at least one mechanism specified in the SIP > > specification. > > Why? This gets into endless arguments as to which is better. > Industry standards consortia should pick one for the network they are designing - not the protocol. If all of the public infrastructure standards consortia agree to use the end to end SA model then that's great. SIP is a protocol that should be flexible enough to support many mechanisms. For instance I might want to use one mechanism for an in-house solution while the public infrastructure may warrant something else. Then again, a military or government organization may wish to use something completely different. Then again, a service provider may way to do something extra if the communications are on net. > > > > It was decided that we should have the following hop-by-hop security > > mechanisms: > > - Server to server: IPSec using ESP transport, > > - Client to server: IPSec using ESP transport (not clear ESP transport > > was agreed to) > > Disagree. For practical reasons, TLS is much easier to deploy (keying, > available libraries, available infrastructure to obtain keys, etc.). Are > there any technical reasons to force somebody to implement IPsec? > This is but one method. Go to a consortia group to get this approved. If a vendor doesn't want to support it - then don't. I do agree that this is a good and scalable choice for a consortia group building a public infrastructure network to make; however, I bet you'll see the other stuff used as well if not in addition to. I guess what I'm saying is "good start" but this choice is probably a bit too simplistic and utopian. Many of these mechanisms are compatible. How many actual providers were at the meeting voicing their opinions? Trust relationships between consumers, business, military, intelligence and government are only compatible to a certain point. There usually is a very good reason for some types of complexity. > > > > 4. Miscellaneous > > ================ > > > > 4.1 Areas needing further work > > ============================== > > - Challenge-response doesn't work with forking (but addresses replay) as > > only one 401 > > will get back to the caller. > > This can be solved, at the cost of increased proxy complexity, by having > the proxy gather all challenges from all branches and return them in the > 401 response, similar to multi-proxy authentication. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFBE98.76901A08 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Minutes of SIP Security task force in Adelaide

    -----Original Message-----
    From:   Henning Schulzrinne = [SMTP:hgs@cs.columbia.edu]
    Sent:   Saturday, May 13, 2000 3:46 AM
    To:     Jonathan Rosenberg
    Cc:     sip
    Subject:       = Re: [SIP] Minutes of SIP Security = task force in Adelaide

    > A number of people participated = in the SIP Security Task Force meeting

    Must have been a really secure meeting = if the identity of the
    participants is secret :-)

    > Jonathan Rosenberg opened the = discussion by suggesting that:
    > - SIP encryption (not = authentication) should be deprecated, because:

    I strongly disagree with this. SIP = encryption serves a number of useful
    purposes. It hides information, for = example, about Contact, Subject,
    Organization, Retry-After, media = types, media IP addresses and meeting
    times (in SDP), SDP k=3D keys, etc. = All of these are irrelevant for proxy
    routing behavior, but highly = sensitive.

    I agree with the = disagreement.=20

    >   o It doesn't work = with NAT and firewalls

    That's a risk you take. I refuse to = dumb down protocols for everybody
    just because some people are behind = firewalls and NATs. There are lots
    of protocols or features that you = can't use behind a firewall or NAT.

    One could consider a = SIP proxy as an ALG and a firewall element, could one not? If you agree = with this then it does work for NAT and firewalls.

    I really sick of = people using "NAT" as a logical fallacy in their arguments. =

    Perhaps if we bury = our heads in the sand long enough they will go away.=20

    >   o It assumes you know = the public key of the party you are calling,
    > which is not a good
    > assumption.

    It works in many cases. In other cases = it can be made to work, e.g., via
    indirection.

    Yep

    >   o It only really = hides the body (and again that doesn't work well due
    > to the above).

    See above.

    >
    > Initial discussion of these = points led to the decision that it should
    > still be possible
    > to support end-to-end encryption = as there may be some uses for it.

    Agreed.

    >
    > A problem with the current = end-to-end encryption scheme is, that it
    > relies on knowing the
    > public key of the other party. = One way of solving that is to return a
    > public key in the
    > response and simply do a = re-INVITE then. However, it was agreed that we
    > should not do
    > that, as we effectively end up = duplicating IKE, or something similar.
    >
    > Dave Oran suggested that = end-to-end information that needs encryption
    > should simply go in
    > the body (don't encrypt = headers). We could use multipart for this, or
    > simply allow for a
    > single body to be encrypted and = define an error code to be returned if
    > the proxy needs to
    > see the body (e.g. if SDP is = encrypted and message traverses a
    > firewall). The group
    > decided to accept this = mechanism. The error code will only support
    > coarse granularity,
    > i.e., if multiple bodies are = encrypted, you will not be told which one
    > is needed in
    > clear, just a general error = saying "body not understood".

    I had originally (many years ago) = suggested a similar mechanism,
    assuming I understand your proposal = correctly, namely to have a body
    type "SIP message", which = is encrypted. A decision was made not to do
    this (I'm afraid I no longer remember = the reason; might have been
    message size concerns or processing = logic). If you only want to encrypt
    SDP, I disagree, for the reasons = stated above. If you want to do both
    and use the "SIP message" = body mechanism, I'm not against this, but this
    does entail a significant protocol = change, without changing any of the
    other problems.

    >
    > Additional discussion on = encryption of headers ensued. Contact is an
    > example of header
    > that can be usefully encrypted = (end-to-end), but in general, there
    > doesn't seem to be a
    > whole lot of use for this = (generally, if the information is relevant it
    > can't be
    > encrypted). Only want the = registrar to see the Contact, not any of the
    > intermediate
    > proxies.

    Again, I disagree, see above.

    I see a plethora of = valuable uses for separate encryption process for the Contact and many = other headers. Especially when there are hierarchies or network = ownership boundaries between UAs, proxies, registrars, ALGs, = etc..

    > 3. AUTHENTICATION = (end-to-end)
    > = =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

    > 3.1 Hop-by-hop = Authentication
    > = =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

    > We want to have at least one = mechanism specified in the SIP
    > specification.

    Why? This gets into endless arguments = as to which is better.

    Industry standards = consortia should pick one for the network they are designing - not the = protocol. If all of the public infrastructure standards consortia agree = to use the end to end SA model then that's great.

    SIP is a protocol = that should be flexible enough to support many mechanisms.

    For instance I might = want to use one mechanism for an in-house solution while the public = infrastructure may warrant something else.

    Then again, a = military or government organization may wish to use something = completely different.

    Then again, a = service provider may way to do something extra if the communications = are on net.

    >
    > It was decided that we should = have the following hop-by-hop security
    > mechanisms:
    > - Server to server: IPSec using = ESP transport,
    > - Client to server: IPSec using = ESP transport (not clear ESP transport
    > was agreed to)

    Disagree. For practical reasons, TLS = is much easier to deploy (keying,
    available libraries, available = infrastructure to obtain keys, etc.). Are
    there any technical reasons to force = somebody to implement IPsec?

    This is but one = method. Go to a consortia group to get this approved. If a vendor = doesn't want to support it - then don't.

    I do agree that this = is a good and scalable choice for a consortia group building a public = infrastructure network to make; however, I bet you'll see the other = stuff used as well if not in addition to. I guess what I'm saying is = "good start" but this choice is probably a bit too simplistic = and utopian.

    Many of these = mechanisms are compatible.

    How many actual = providers were at the meeting voicing their opinions?

    Trust relationships = between consumers, business, military, intelligence and government are = only compatible to a certain point. There usually is a very good reason = for some types of complexity.

    >
    > 4. Miscellaneous
    > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    >
    > 4.1 Areas needing further = work
    > = =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
    > - Challenge-response doesn't = work with forking (but addresses replay) as
    > only one 401
    > will get back to the = caller.

    This can be solved, at the cost of = increased proxy complexity, by having
    the proxy gather all challenges from = all branches and return them in the
    401 response, similar to multi-proxy = authentication.

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

------_=_NextPart_001_01BFBE98.76901A08-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 14:54:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08694 for ; Mon, 15 May 2000 14:54:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37F4844380; Mon, 15 May 2000 14:45:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.fore.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 942D544336 for ; Mon, 15 May 2000 14:44:28 -0400 (EDT) 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 OAA11737; Mon, 15 May 2000 14:51:16 -0400 (EDT) Received: from whq-msgrtr-01.fore.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 OAA13730; Mon, 15 May 2000 14:51:13 -0400 (EDT) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 May 2000 14:45:15 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF6782BF@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Glenn Morrow'" , "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: sip Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Mon, 15 May 2000 14:51:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBE9D.B5618BB8" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFBE9D.B5618BB8 Content-Type: text/plain; charset="ISO-8859-1" The problem with having 25 mechanisms for security is that the probability of being able to build a secure system goes down because different vendors make different choices and thus we get non-interoperability and even the probability of having any solution implemented in a given instance goes down. I would prefer to see one less than perfect solution that works most of the time then 25 solutions, each perfect for one kind of system. The existing mechanisms aren't close to good enough for such a status. There are already too many options. I don't really care what mechanism we choose as as long as we pick one, and then really work towards getting everyone to implement it. The present situation, which AFAIK there a precious few implementations, and does not provide an adequate level of security, is not satisfactory. Augmenting it with lots more alternatives is not satisfactory. Brian -----Original Message----- From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com] Sent: Monday, May 15, 2000 2:08 PM To: 'Henning Schulzrinne'; Jonathan Rosenberg Cc: sip Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide -----Original Message----- From: Henning Schulzrinne [SMTP:hgs@cs.columbia.edu] Sent: Saturday, May 13, 2000 3:46 AM To: Jonathan Rosenberg Cc: sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide > A number of people participated in the SIP Security Task Force meeting Must have been a really secure meeting if the identity of the participants is secret :-) > Jonathan Rosenberg opened the discussion by suggesting that: > - SIP encryption (not authentication) should be deprecated, because: I strongly disagree with this. SIP encryption serves a number of useful purposes. It hides information, for example, about Contact, Subject, Organization, Retry-After, media types, media IP addresses and meeting times (in SDP), SDP k= keys, etc. All of these are irrelevant for proxy routing behavior, but highly sensitive. I agree with the disagreement. > o It doesn't work with NAT and firewalls That's a risk you take. I refuse to dumb down protocols for everybody just because some people are behind firewalls and NATs. There are lots of protocols or features that you can't use behind a firewall or NAT. One could consider a SIP proxy as an ALG and a firewall element, could one not? If you agree with this then it does work for NAT and firewalls. I really sick of people using "NAT" as a logical fallacy in their arguments. Perhaps if we bury our heads in the sand long enough they will go away. > o It assumes you know the public key of the party you are calling, > which is not a good > assumption. It works in many cases. In other cases it can be made to work, e.g., via indirection. Yep > o It only really hides the body (and again that doesn't work well due > to the above). See above. > > Initial discussion of these points led to the decision that it should > still be possible > to support end-to-end encryption as there may be some uses for it. Agreed. > > A problem with the current end-to-end encryption scheme is, that it > relies on knowing the > public key of the other party. One way of solving that is to return a > public key in the > response and simply do a re-INVITE then. However, it was agreed that we > should not do > that, as we effectively end up duplicating IKE, or something similar. > > Dave Oran suggested that end-to-end information that needs encryption > should simply go in > the body (don't encrypt headers). We could use multipart for this, or > simply allow for a > single body to be encrypted and define an error code to be returned if > the proxy needs to > see the body (e.g. if SDP is encrypted and message traverses a > firewall). The group > decided to accept this mechanism. The error code will only support > coarse granularity, > i.e., if multiple bodies are encrypted, you will not be told which one > is needed in > clear, just a general error saying "body not understood". I had originally (many years ago) suggested a similar mechanism, assuming I understand your proposal correctly, namely to have a body type "SIP message", which is encrypted. A decision was made not to do this (I'm afraid I no longer remember the reason; might have been message size concerns or processing logic). If you only want to encrypt SDP, I disagree, for the reasons stated above. If you want to do both and use the "SIP message" body mechanism, I'm not against this, but this does entail a significant protocol change, without changing any of the other problems. > > Additional discussion on encryption of headers ensued. Contact is an > example of header > that can be usefully encrypted (end-to-end), but in general, there > doesn't seem to be a > whole lot of use for this (generally, if the information is relevant it > can't be > encrypted). Only want the registrar to see the Contact, not any of the > intermediate > proxies. Again, I disagree, see above. I see a plethora of valuable uses for separate encryption process for the Contact and many other headers. Especially when there are hierarchies or network ownership boundaries between UAs, proxies, registrars, ALGs, etc.. > 3. AUTHENTICATION (end-to-end) > ============================== > 3.1 Hop-by-hop Authentication > ============================= > We want to have at least one mechanism specified in the SIP > specification. Why? This gets into endless arguments as to which is better. Industry standards consortia should pick one for the network they are designing - not the protocol. If all of the public infrastructure standards consortia agree to use the end to end SA model then that's great. SIP is a protocol that should be flexible enough to support many mechanisms. For instance I might want to use one mechanism for an in-house solution while the public infrastructure may warrant something else. Then again, a military or government organization may wish to use something completely different. Then again, a service provider may way to do something extra if the communications are on net. > > It was decided that we should have the following hop-by-hop security > mechanisms: > - Server to server: IPSec using ESP transport, > - Client to server: IPSec using ESP transport (not clear ESP transport > was agreed to) Disagree. For practical reasons, TLS is much easier to deploy (keying, available libraries, available infrastructure to obtain keys, etc.). Are there any technical reasons to force somebody to implement IPsec? This is but one method. Go to a consortia group to get this approved. If a vendor doesn't want to support it - then don't. I do agree that this is a good and scalable choice for a consortia group building a public infrastructure network to make; however, I bet you'll see the other stuff used as well if not in addition to. I guess what I'm saying is "good start" but this choice is probably a bit too simplistic and utopian. Many of these mechanisms are compatible. How many actual providers were at the meeting voicing their opinions? Trust relationships between consumers, business, military, intelligence and government are only compatible to a certain point. There usually is a very good reason for some types of complexity. > > 4. Miscellaneous > ================ > > 4.1 Areas needing further work > ============================== > - Challenge-response doesn't work with forking (but addresses replay) as > only one 401 > will get back to the caller. This can be solved, at the cost of increased proxy complexity, by having the proxy gather all challenges from all branches and return them in the 401 response, similar to multi-proxy authentication. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFBE9D.B5618BB8 Content-Type: text/html; charset="ISO-8859-1" RE: [SIP] Minutes of SIP Security task force in Adelaide
The problem with having 25 mechanisms for security is that the probability of
being able to build a secure system goes down because different vendors make different choices and thus we get non-interoperability and even the probability of having any
solution implemented in a given instance goes down.
 
I would prefer to see one less than perfect solution that works most of the time
then 25 solutions, each perfect for one kind of system.   The existing mechanisms
aren't close to good enough for such a status.  There are already too many options.
 
I don't really care what mechanism we choose as as long as we pick one,
and then really work towards getting everyone to implement it.  The present situation,
which AFAIK there a precious few implementations, and does not provide an adequate
level of security, is not satisfactory.  Augmenting it with lots more alternatives is not
satisfactory.
 
Brian
-----Original Message-----
From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com]
Sent: Monday, May 15, 2000 2:08 PM
To: 'Henning Schulzrinne'; Jonathan Rosenberg
Cc: sip
Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide



    -----Original Message-----
    From:   Henning Schulzrinne [SMTP:hgs@cs.columbia.edu]
    Sent:   Saturday, May 13, 2000 3:46 AM
    To:     Jonathan Rosenberg
    Cc:     sip
    Subject:        Re: [SIP] Minutes of SIP Security task force in Adelaide

    > A number of people participated in the SIP Security Task Force meeting

    Must have been a really secure meeting if the identity of the
    participants is secret :-)

    > Jonathan Rosenberg opened the discussion by suggesting that:
    > - SIP encryption (not authentication) should be deprecated, because:

    I strongly disagree with this. SIP encryption serves a number of useful
    purposes. It hides information, for example, about Contact, Subject,
    Organization, Retry-After, media types, media IP addresses and meeting
    times (in SDP), SDP k= keys, etc. All of these are irrelevant for proxy
    routing behavior, but highly sensitive.

    I agree with the disagreement.

    >   o It doesn't work with NAT and firewalls

    That's a risk you take. I refuse to dumb down protocols for everybody
    just because some people are behind firewalls and NATs. There are lots
    of protocols or features that you can't use behind a firewall or NAT.

    One could consider a SIP proxy as an ALG and a firewall element, could one not? If you agree with this then it does work for NAT and firewalls.

    I really sick of people using "NAT" as a logical fallacy in their arguments.

    Perhaps if we bury our heads in the sand long enough they will go away.

    >   o It assumes you know the public key of the party you are calling,
    > which is not a good
    > assumption.

    It works in many cases. In other cases it can be made to work, e.g., via
    indirection.

    Yep

    >   o It only really hides the body (and again that doesn't work well due
    > to the above).

    See above.

    >
    > Initial discussion of these points led to the decision that it should
    > still be possible
    > to support end-to-end encryption as there may be some uses for it.

    Agreed.

    >
    > A problem with the current end-to-end encryption scheme is, that it
    > relies on knowing the
    > public key of the other party. One way of solving that is to return a
    > public key in the
    > response and simply do a re-INVITE then. However, it was agreed that we
    > should not do
    > that, as we effectively end up duplicating IKE, or something similar.
    >
    > Dave Oran suggested that end-to-end information that needs encryption
    > should simply go in
    > the body (don't encrypt headers). We could use multipart for this, or
    > simply allow for a
    > single body to be encrypted and define an error code to be returned if
    > the proxy needs to
    > see the body (e.g. if SDP is encrypted and message traverses a
    > firewall). The group
    > decided to accept this mechanism. The error code will only support
    > coarse granularity,
    > i.e., if multiple bodies are encrypted, you will not be told which one
    > is needed in
    > clear, just a general error saying "body not understood".

    I had originally (many years ago) suggested a similar mechanism,
    assuming I understand your proposal correctly, namely to have a body
    type "SIP message", which is encrypted. A decision was made not to do
    this (I'm afraid I no longer remember the reason; might have been
    message size concerns or processing logic). If you only want to encrypt
    SDP, I disagree, for the reasons stated above. If you want to do both
    and use the "SIP message" body mechanism, I'm not against this, but this
    does entail a significant protocol change, without changing any of the
    other problems.

    >
    > Additional discussion on encryption of headers ensued. Contact is an
    > example of header
    > that can be usefully encrypted (end-to-end), but in general, there
    > doesn't seem to be a
    > whole lot of use for this (generally, if the information is relevant it
    > can't be
    > encrypted). Only want the registrar to see the Contact, not any of the
    > intermediate
    > proxies.

    Again, I disagree, see above.

    I see a plethora of valuable uses for separate encryption process for the Contact and many other headers. Especially when there are hierarchies or network ownership boundaries between UAs, proxies, registrars, ALGs, etc..

    > 3. AUTHENTICATION (end-to-end)
    > ==============================

    > 3.1 Hop-by-hop Authentication
    > =============================

    > We want to have at least one mechanism specified in the SIP
    > specification.

    Why? This gets into endless arguments as to which is better.

    Industry standards consortia should pick one for the network they are designing - not the protocol. If all of the public infrastructure standards consortia agree to use the end to end SA model then that's great.

    SIP is a protocol that should be flexible enough to support many mechanisms.

    For instance I might want to use one mechanism for an in-house solution while the public infrastructure may warrant something else.

    Then again, a military or government organization may wish to use something completely different.

    Then again, a service provider may way to do something extra if the communications are on net.

    >
    > It was decided that we should have the following hop-by-hop security
    > mechanisms:
    > - Server to server: IPSec using ESP transport,
    > - Client to server: IPSec using ESP transport (not clear ESP transport
    > was agreed to)

    Disagree. For practical reasons, TLS is much easier to deploy (keying,
    available libraries, available infrastructure to obtain keys, etc.). Are
    there any technical reasons to force somebody to implement IPsec?

    This is but one method. Go to a consortia group to get this approved. If a vendor doesn't want to support it - then don't.

    I do agree that this is a good and scalable choice for a consortia group building a public infrastructure network to make; however, I bet you'll see the other stuff used as well if not in addition to. I guess what I'm saying is "good start" but this choice is probably a bit too simplistic and utopian.

    Many of these mechanisms are compatible.

    How many actual providers were at the meeting voicing their opinions?

    Trust relationships between consumers, business, military, intelligence and government are only compatible to a certain point. There usually is a very good reason for some types of complexity.

    >
    > 4. Miscellaneous
    > ================
    >
    > 4.1 Areas needing further work
    > ==============================
    > - Challenge-response doesn't work with forking (but addresses replay) as
    > only one 401
    > will get back to the caller.

    This can be solved, at the cost of increased proxy complexity, by having
    the proxy gather all challenges from all branches and return them in the
    401 response, similar to multi-proxy authentication.

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

------_=_NextPart_001_01BFBE9D.B5618BB8-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 14:57:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08760 for ; Mon, 15 May 2000 14:57:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2DFB644369; Mon, 15 May 2000 14:49:39 -0400 (EDT) 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 66D5F4433E for ; Mon, 15 May 2000 14:49:35 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA18075; Mon, 15 May 2000 11:49:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA25169; Mon, 15 May 2000 11:49:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14624.18086.838767.469304@thomasm-u1.cisco.com> Date: Mon, 15 May 2000 11:49:10 -0700 (PDT) To: Giuseppe Ricagni Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <392019ED.A97587BF@italtel.it> References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Giuseppe Ricagni writes: > * possible optimizations (e.g.: signalling for a basic call to an Australian > fixed network number from an Italian mobile roaming to Australia could be > processed locally, without any "tromboning") If during call setup there needs to be a round trip to the home network, it pretty much negates any advantage of proxying the call locally. > * some people claim the "proxy" should also perform some kind of admission > control for the calls. The proxy in the home domain has no information on the > visited domain This is true of the foreign domain too. How does any proxy have knowledge of network topology? > * the PNO who runs the visited network might desire to have some kind of > knowledge on what is going on in his network, from a call control point of > view Absolutely. However, admission control can be done through other means. Namely, you could use RSVP to signal your intent to consume some air resources and authenticate/authorize that traffic. SIP normally has no part in bandwidth allocation, which is a feature not a bug. Even if you believe the manyfolks (DQoS) model of implicit linkage, I still don't see why there is any advantage to having a local proxy do call routing vs my home proxy. I can think of a lot of disadvantages though. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 16:02:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09481 for ; Mon, 15 May 2000 16:02:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DA644433E; Mon, 15 May 2000 15:55:01 -0400 (EDT) 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 BD62E44336 for ; Mon, 15 May 2000 15:54:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 15 16:01:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8FF5444341; Mon, 15 May 2000 15:37:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 424DB44346 for ; Mon, 15 May 2000 15:37:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D949B52B6; Mon, 15 May 2000 15:37:18 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F31BB52C4 for ; Mon, 15 May 2000 15:37:16 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 15 15:36:55 EDT 2000 Received: from mail-blue.research.att.com ([135.207.30.102]) by dusty; Mon May 15 15:36:54 EDT 2000 Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id A13604CE02 for ; Mon, 15 May 2000 15:36:50 -0400 (EDT) Received: from research.att.com (dhcp-new153.research.att.com [135.207.19.153]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id PAA08688 for ; Mon, 15 May 2000 15:36:50 -0400 (EDT) Message-ID: <3920519B.6E9E2281@research.att.com> Date: Mon, 15 May 2000 15:35:55 -0400 From: "Gregory W. Bond" Organization: AT&T Labs - Research, Florham Park, NJ X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] 2nd CFP: IP Telecom Services Workshop 2000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit [Please accept our apologies for multiple copies of this call.] ------------- SECOND CALL FOR PAPERS --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 submission deadline: June 16, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. The IPTS 2000 Program Committee invites submission of papers on substantial, original and previously unpublished research in IP telecom services, including, but not limited to: - service architectures (e.g. AIN, SoftSwitch, JAIN, Parlay, DFC) - service creation environments - protocols, standards and interoperability (e.g. H.323, SIP, MGCP, Megaco/H.248, etc.) - service programming languages - service management - billing, fault tolerance, monitoring - novel services We welcome papers describing original research; position papers describing research interests in the field, work in progress, or future directions of research; project or system descriptions. IMPORTANT DATES June 16, 2000 Submission deadline July 21, 2000 Notification of acceptance August 25, 2000 Final version of papers September 11, 2000 IPTS 2000 PAPER SUBMISSIONS Papers must describe original, previously unpublished work that has not been simultaneously submitted for publication elsewhere. They must be written in English, not exceeding 6 pages including figures, tables and references in 10-12 point font on 8.5x11-inch (US letter) paper. The first page must include an abstract of up to 200 words, keywords, and email address of the corresponding author. All papers must be submitted electronically unless specifically approved by the Workshop Co-Chairs. Submissions in PostScript or PDF format should be sent to mailto:ipts2000@research.att.com. Authors of accepted papers are expected to present their contribution at the workshop. The proceedings will be published in hardcopy and on the web. REVIEW PROCEDURE All submissions will be subject to academic peer review by the IPTS 2000 Program Committee under the chairmanship of the Workshop Co-Chairs. Each paper will receive three written reviews, and reviews will be returned to the authors. The Workshop Co-Chairs have final authority over the review process and all decisions relating to acceptance of papers. Review criteria include originality of ideas, technical soundness, significance of results, and quality of presentation. CONFERENCE VENUE AND RELATED EVENTS IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Details about Fall 2000 VON can be found at http://pulver.com. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 17:08:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10076 for ; Mon, 15 May 2000 17:08:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EAAFE44367; Mon, 15 May 2000 17:00:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BC7A844336 for ; Mon, 15 May 2000 17:00:43 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA20905; Mon, 15 May 2000 17:08:45 -0400 (EDT) Message-ID: <392069CC.17A9737D@dynamicsoft.com> Date: Mon, 15 May 2000 17:19:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow Cc: "'Henning Schulzrinne'" , sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Glenn Morrow wrote: > > > Jonathan Rosenberg opened the discussion by suggesting that: > > - SIP encryption (not authentication) should be deprecated, > because: > > I strongly disagree with this. SIP encryption serves a number of > useful > purposes. It hides information, for example, about Contact, > Subject, > Organization, Retry-After, media types, media IP addresses and > meeting > times (in SDP), SDP k= keys, etc. All of these are irrelevant for > proxy > routing behavior, but highly sensitive. > > I agree with the disagreement. There isn't really any disagreement. I made this obviously bold statement as an expression of my concerns with relying on end to end as the sole mechanism for privacy. In the end, we did agree that it should stay. > > > o It doesn't work with NAT and firewalls > > That's a risk you take. I refuse to dumb down protocols for > everybody > just because some people are behind firewalls and NATs. There are > lots > of protocols or features that you can't use behind a firewall or > NAT. > > One could consider a SIP proxy as an ALG and a firewall element, > could one not? If you agree with this then it does work for NAT > and firewalls. No, this does *not* work. The body of the SIP message is encrypted with the public key of the target in the To field. This is therefore not readable by anyone except the recipient, which means that NAT, co-located with a proxy or otherwise, can't see it. Normal proxies don't need to see it, but an ALG does. Thats why SIP doesn't work through NATs when encrypted. But, hop by hop does work, since the proxy can decrypt the message. Anyway, I believe there are uses for e2e encryption. Like everything else in engineering, its a tradeoff. Go for top notch security, and you get no services. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 15 18:19:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10907 for ; Mon, 15 May 2000 18:19:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 591DE4441E; Mon, 15 May 2000 17:14:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7D8F444425 for ; Mon, 15 May 2000 17:14:16 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA21032; Mon, 15 May 2000 17:22:39 -0400 (EDT) Message-ID: <39206D0E.B3CD7B08@dynamicsoft.com> Date: Mon, 15 May 2000 17:33:02 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <391A0713.5A7AC492@dynamicsoft.com> <391D1635.C81EDDD3@cs.columbia.edu> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Henning Schulzrinne wrote: > > > 4.1 Areas needing further work > > ============================== > > - Challenge-response doesn’t work with forking (but addresses replay) as > > only one 401 > > will get back to the caller. > > This can be solved, at the cost of increased proxy complexity, by having > the proxy gather all challenges from all branches and return them in the > 401 response, similar to multi-proxy authentication. This is an interesting idea. I like it. An interesting question arises when you get *both* 401s and 407s. I guess the proxy could return a 401, and place into the 401 WWW-Authenticate headers from the 401s it received, and Proxy-Authenticate headers from the 407s. A UA would need to be smart and look for both headers in a 401, however. Any other interactions...? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 15 18:23:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10942 for ; Mon, 15 May 2000 18:23:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C2C854444B; Mon, 15 May 2000 17:29:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out4.prserv.net [32.97.166.34]) by lists.bell-labs.com (Postfix) with ESMTP id E3B9D44446 for ; Mon, 15 May 2000 17:29:20 -0400 (EDT) Received: from cs.columbia.edu ([139.92.232.159]) by prserv.net (out4) with SMTP id <2000051521362023900l4kg4e>; Mon, 15 May 2000 21:36:21 +0000 Message-ID: <39206052.CAF9415A@cs.columbia.edu> Date: Mon, 15 May 2000 16:38:42 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas , Jonathan Rosenberg , sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <391A0713.5A7AC492@dynamicsoft.com> <391D1635.C81EDDD3@cs.columbia.edu> <14621.33050.682399.735419@thomasm-u1.cisco.com> <391DD714.BA3EFEFB@cs.columbia.edu> <14623.3302.169458.272648@thomasm-u1.cisco.com> <39205505.748F8E63@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rather than do nesting of >, maybe we can make progress by summarizing, as several different problems seem to be discussed at the same time: - e2e authentication and/or encryption across domains: Useful primarily for authenticated call filtering and key exchange for media encryption. Scalable probably for intelligent end systems, at the possible penalty of call setup delay. If truly e2e, requires per-user public keys, which do not seem imminent (although some organizations are apparently working on this, mostly for internal purchasing use). Semi-e2e might use Kerberos, local proxy digest authentication or other h2h mechanism (see below) to authenticate and secure the local hop, with proxy-secured signaling. This only requires a PK for each organization, readily obtained from Verisign and their various competitors that would be recognized in web browsers. This would essentially be a model similar to today's web model, which seems to work satisfactorily in the absence of a true PKI. Proxy-based security probably scales easily (in the typical CPU-dedicated-to-server installation) to a few thousand calls a day (i.e., it would work for typical departments), based on rough assumptions of SSL servers. (Is there an SSL/TLS benchmark test for web servers?) [TLS plays no role here, just probably has similar performance.] - h2h mechanisms *across* domains This seems to be the hard problem. Just specifying IPsec without an IKE doesn't help much to achieve interoperability. Is it even plausible to run basically every single IKE version and variation on a proxy, to be able to talk to every other domain? Would PKCROSS be sufficiently acceptable to every other proxy operator to use it exclusively? Is there operational experience with large-scale use of this? The number of public key operations would seem to be the same with PKCROSS or direct proxy-to-proxy use of some IKE or TLS, depending solely on the sparsity of proxy relationships. PKCROSS would presumably have the advantage of splitting this across two (sets of) machines, but unless this is used for something else much "bigger" and can thus ride the coattails of an existing application, the net number of boxes seems comparable. For TLS, while restricted to TCP, there's operational experience and a well-known infrastructure for obtaining certificates; most organizations would already have such a certificate for their secure web server. This problem seems much harder than that faced by typical sigtran or MGCP/Megaco applications, where (for Megaco) this is mostly intradomain or for sigtran a smallish number of well-known peers instead of every ISP and organization-with-a-SIP-address on the planet. Thus, the scalability depends on the fraction of SIP calls that require SA setup. One could presumably look at mail server logs to see if, say, 80% of the messages go to 100 domains with lots of traffic per PK operation, so that only 20% would require per-call SA establishment. Besides the usual 80-20 rule, I have no indications what, if any, scaling advantage will accrue due to such uneven distribution of call destinations. - h2h *within* a domain Relatively easy, since one can agree on either a single IKE or (most likely currently) IKE implementation, with alternatives such as Kerberos or just about anything else feasible according to what's available locally. (E.g., Microsoft-only shops might use the Microsoft flavor and not care about any interoperability problems with the rest of the world. Or, for authentication only, somebody might draw on CHAP authentication.) Specifying a single or small number of architectures is probably helpful, but to a somewhat more limited extent than in the inter-domain case, since single organizations usually have a mechanism to agree on things. Specifying Kerberos seems like an easy step forward here. If applications use GSSAPI, this is probably largely invisible to the application writer. Henning _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 15 18:26:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10965 for ; Mon, 15 May 2000 18:26:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1209644498; Mon, 15 May 2000 18:12:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B42D844496 for ; Mon, 15 May 2000 18:12:06 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA21404; Mon, 15 May 2000 18:20:00 -0400 (EDT) Message-ID: <39207A7F.52337CDD@dynamicsoft.com> Date: Mon, 15 May 2000 18:30:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Cc: "'Glenn Morrow'" , "'Henning Schulzrinne'" , sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <4FBEA8857476D311A03300204840E1CF6782BF@whq-msgusr-02.fore.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > The problem with having 25 mechanisms for security is that the probability of > being able to build a secure system goes down because different vendors make different choices and thus we get > non-interoperability and even the probability of having any > solution implemented in a given instance goes down. > > I would prefer to see one less than perfect solution that works most of the time > then 25 solutions, each perfect for one kind of system. The existing mechanisms > aren't close to good enough for such a status. There are already too many options. > > I don't really care what mechanism we choose as as long as we pick one, > and then really work towards getting everyone to implement it. The present situation, > which AFAIK there a precious few implementations, and does not provide an adequate > level of security, is not satisfactory. Augmenting it with lots more alternatives is not > satisfactory. I have no problems with alternatives if there is some kind of baseline that everyone does. The situation is similar with codecs; there are lots of choices, and sometimes people specify a baseline. Interestingly, SIP/SDP has never specified a baseline codec, nor can we, I don't think. Every seems to do G.711, so things work. We all know the fun involved in standardizing baseline low rate codecs... So, the question to me is this: should we, or need we, specify baseline (i.e., mandatory if you do security at all) mechanisms for e2e and hop by hop, or do we let the industry effectively pick a defacto? Brian has argued that letting the industry pick one will lead to interop problems, since it effectively might not pick one. Others will argue that we will never be able to pick one, since there is no clear winner. I don't have an easy answer for this, since its more business/political/procedural than it is technical. I would actually look to the ADs for input; is it necessary for an application layer protocol to pick baseline mandatory-to-implement security mechanisms? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 15 19:01:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11307 for ; Mon, 15 May 2000 19:01:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D300244388; Mon, 15 May 2000 18:54:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8182A4437C for ; Mon, 15 May 2000 18:54:18 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA21548; Mon, 15 May 2000 18:47:25 -0400 (EDT) Message-ID: <392080EB.5047280@dynamicsoft.com> Date: Mon, 15 May 2000 18:57:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Giuseppe Ricagni , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Let me chime in with strong support of what Mike is saying. One of the great strengths of SIP is that there is a complete separation of transport (i.e.,voice) from signaling (read: services). This means that I can buy my transport and access for VoIp from one provider, but get applications and services from one or more other providers. This provide disaggregation of what has traditionally been a coupled service offering. Such disaggregation opens the door to massive innovation in the services area, since any yahoo can buy application hosting services, run on application on the hosted providers SIP servers, and provide service to anyone in the world, accessing from any IP device, wireless included. This is the model that made the web successful. Would it had evolved if ONLY my ISP could provide web content? No way. There would *never* had been a web if content and services for web had been coupled to access and transport. Never. Please lets not make this mistake with communications services. Efforts to link transport and access with services and signaling on the Internet are fundamentally futile, flawed, and will, in the end, reduce competition and innovation. But, I suppose thats the point. So, as it relates to wireless, just because some local provider is offering me transport services does not mean I should be forced to use them for signaling and features. Michael Thomas wrote: > > Giuseppe Ricagni writes: > > * possible optimizations (e.g.: signalling for a basic call to an Australian > > fixed network number from an Italian mobile roaming to Australia could be > > processed locally, without any "tromboning") > > If during call setup there needs to be a round > trip to the home network, it pretty much negates > any advantage of proxying the call locally. Please note that this service (optimized dial plans based on roaming) is still possible even if I go directly to the home network. All I need to do is indicate to my home proxy where I am, so it knows what dial plan to apply. In fact, dial plan administration is, in general, a service that can be outsourced to any ASP (of course, only local ASPs may wish to provide it, but the point is anyone can). > > > * some people claim the "proxy" should also perform some kind of admission > > control for the calls. The proxy in the home domain has no information on the > > visited domain > > This is true of the foreign domain too. How does > any proxy have knowledge of network topology? Call admission control in proxies >>will never work<<. As Mike suggests, this belongs in the transport layer, not the signaling layer. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 16 03:57:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29354 for ; Tue, 16 May 2000 03:57:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B6CE44375; Tue, 16 May 2000 03:50:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out5.prserv.net [32.97.166.35]) by lists.bell-labs.com (Postfix) with ESMTP id C895F44336 for ; Tue, 16 May 2000 03:50:09 -0400 (EDT) Received: from cs.columbia.edu ([139.92.232.171]) by prserv.net (out5) with SMTP id <2000051607564524301dic1pe>; Tue, 16 May 2000 07:56:46 +0000 Message-ID: <3920741B.B0F8E092@cs.columbia.edu> Date: Mon, 15 May 2000 18:03:07 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Glenn Morrow , sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <392069CC.17A9737D@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > No, this does *not* work. The body of the SIP message is encrypted with > the public key of the target in the To field. This is therefore not > readable by anyone except the recipient, which means that NAT, > co-located with a proxy or otherwise, can't see it. Normal proxies don't > need to see it, but an ALG does. Thats why SIP doesn't work through NATs > when encrypted. But, hop by hop does work, since the proxy can decrypt > the message. The NAT issue is more general, in that we could imagine, for example, a different payload format than SDP, say for event notification or as SDPng. In all such cases, the ALG would have to return some status code and refuse the call or hope that there are no IP addresses in the part hidden (after all, if the inside-NAT-host is send-only, it wouldn't much matter - not a course of action I'd recommend). It then becomes the decision of the parties involved whether to complain to the NAT/ALG builder, get the admin that got the company into NATs fired or reduce their expectation of the level of service. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 08:04:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02932 for ; Tue, 16 May 2000 08:04:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EDE194437E; Tue, 16 May 2000 07:57:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id E0A1444336 for ; Tue, 16 May 2000 07:57:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14438; Tue, 16 May 2000 06:04:07 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA18548; Tue, 16 May 2000 05:03:52 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id FAA13329; Tue, 16 May 2000 05:03:07 -0700 (PDT) From: James Kempf Message-Id: <200005161203.FAA13329@nasnfs.eng.sun.com> Date: Tue, 16 May 2000 05:05:52 -0700 To: "Michael Thomas" , "Giuseppe Ricagni" Cc: , , "James Kempf" , "Michael Thomas" Reply-To: Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >Giuseppe Ricagni writes: > > * possible optimizations (e.g.: signalling for a basic call to an >Australian > > fixed network number from an Italian mobile roaming to Australia could >be > > processed locally, without any "tromboning") > > If during call setup there needs to be a round > trip to the home network, it pretty much negates > any advantage of proxying the call locally. > When you take roaming into account, there is an advantage. Suppose the Italian now in Australia moves. If the home proxy is used, the network has to go back to the home to roam. If a local proxy is used, there is reduced latency. With a local proxy, you pay the round trip cost to the home network just once. In addition, some people have been talking about using SIP for other kinds of in-call signalling. If the mobile has to go all the way back to the home proxy, there is simply too much latency. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 08:39:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03922 for ; Tue, 16 May 2000 08:39:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF828443A2; Tue, 16 May 2000 08:31:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id 1E13F44336 for ; Tue, 16 May 2000 08:31:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00702; Tue, 16 May 2000 06:38:11 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA15582; Tue, 16 May 2000 05:37:59 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id FAA13968; Tue, 16 May 2000 05:37:19 -0700 (PDT) From: James Kempf Message-Id: <200005161237.FAA13968@nasnfs.eng.sun.com> Date: Tue, 16 May 2000 05:39:58 -0700 To: "Jonathan Rosenberg" , "Michael Thomas" Cc: , "James Kempf" , "Giuseppe Ricagni" Reply-To: Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, Unfortunately, I have to respectfully disagree. I don't think the analogy between SIP and HTTP is valid. I see it more as being between SIP and routing. Suppose I would have to go all the way back to my home network to get my packets routed. I view SIP as being a way of doing the kind of things that routing protocols do, except at the application layer. The network of SIP proxies is performing telephone call routing. Even if you are willing to grant the analogy, HTTP requests nowadays often don't get routed to the server that somebody set up as their web site. If your ISP is concerned about service, they may have set up an Inktomi cache, and if the publisher is concerned, they may have contracted with Akami to do the same. So the world is not so simple as "let's make it free and easy for anybody to set up service" on the Web anymore. You can set up your service, but unless you have a concerned ISP or the money to pay Akami, the latency in using your service may cause people to go elsewhere. I know this isn't going to be a popular viewpoint, but I think we need to be realistic about the design. SIP already contains support for telling an incoming caller that a client has moved, I can't see the harm in using a remote proxy, given the performance concerns. jak >Let me chime in with strong support of what Mike is saying. One of the >great strengths of SIP is that there is a complete separation of >transport (i.e.,voice) from signaling (read: services). This means that >I can buy my transport and access for VoIp from one provider, but get >applications and services from one or more other providers. This provide >disaggregation of what has traditionally been a coupled service >offering. Such disaggregation opens the door to massive innovation in >the services area, since any yahoo can buy application hosting services, >run on application on the hosted providers SIP servers, and provide >service to anyone in the world, accessing from any IP device, wireless >included. > >This is the model that made the web successful. Would it had evolved if >ONLY my ISP could provide web content? No way. There would *never* had >been a web if content and services for web had been coupled to access >and transport. Never. Please lets not make this mistake with >communications services. > >Efforts to link transport and access with services and signaling on the >Internet are fundamentally futile, flawed, and will, in the end, reduce >competition and innovation. But, I suppose thats the point. > >So, as it relates to wireless, just because some local provider is >offering me transport services does not mean I should be forced to use >them for signaling and features. > >Michael Thomas wrote: >> >> Giuseppe Ricagni writes: >> > * possible optimizations (e.g.: signalling for a basic call to an >Australian >> > fixed network number from an Italian mobile roaming to Australia could >be >> > processed locally, without any "tromboning") >> >> If during call setup there needs to be a round >> trip to the home network, it pretty much negates >> any advantage of proxying the call locally. > >Please note that this service (optimized dial plans based on roaming) is >still possible even if I go directly to the home network. All I need to >do is indicate to my home proxy where I am, so it knows what dial plan >to apply. In fact, dial plan administration is, in general, a service >that can be outsourced to any ASP (of course, only local ASPs may wish >to provide it, but the point is anyone can). > >> >> > * some people claim the "proxy" should also perform some kind of >admission >> > control for the calls. The proxy in the home domain has no information >on the >> > visited domain >> >> This is true of the foreign domain too. How does >> any proxy have knowledge of network topology? > >Call admission control in proxies >>will never work<<. As Mike suggests, >this belongs in the transport layer, not the signaling layer. > >-Jonathan R. >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (732) 741-4778 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >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 May 16 08:40:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03954 for ; Tue, 16 May 2000 08:40:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A48444336; Tue, 16 May 2000 08:31:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by lists.bell-labs.com (Postfix) with ESMTP id D2C8F44392 for ; Tue, 16 May 2000 08:31:19 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id IAA06161; Tue, 16 May 2000 08:38:00 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568E1.004561AD ; Tue, 16 May 2000 08:37:49 -0400 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: Michael Thomas Cc: James Kempf , mat@cisco.com, sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Message-ID: <852568E1.00456034.00@notes949.cc.telcordia.com> Date: Tue, 16 May 2000 08:36:44 -0400 Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com As far as whether to talk to the home proxy or local proxy, for a wireless roaming user which is changing domains frequently during mid-session-call and is on the move, it may be better to talk to the local proxy rather than going to the home proxy all the way during every hand-off (for latency reason I guess), of course there needs to be a security association between the local-proxy and home proxy or via public-proxy. This is one of the things we were trying to debate during SIP-2000 conference in Paris last week to see the trade-off between either talking to home-proxy or local domain proxy during frequent hand-off, then there is also a possibility of interaction between local SIP server and AAA server for a roaming user's profile verification during domain handoff. Thanks Ashutosh _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 08:51:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04218 for ; Tue, 16 May 2000 08:51:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CE90844398; Tue, 16 May 2000 08:43:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 71F2E44396 for ; Tue, 16 May 2000 08:43:39 -0400 (EDT) Date: Tue, 16 May 2000 14:53:14 +0200 (CEST) From: Lars Berggren To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Comments on Session Timer draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com After reading the draft-ietf-sip-session-timer-01.txt I have some comments. For the Session Timer to be applied for a call leg, the specifications in the draft requires that both the UAC and UAS understand the extension (See example 8.5). However, since the keep-alive mechanism is achieved by sending 'standard' re-INVITEs, it is sufficient (and useful) that at least one of the parties is aware of the Session Timer to accomplish a keep-alive mechanism. The usefulness of such an approach is for example when a UAC supports 'timer', a stateful proxy server, SPS, wants to apply a Session Timer to the call and the UAS doesn't understand the extension. Consider the example 8.5 in the draft: > Calling UA -> SPS > INVITE > k: timer > > SPS -> Called UA > INVITE SPS adds S-E header > k: timer > Session-Expires: 180 > > SPS <- Called UA > 200 OK Called UA doesn't understand session timer > > Calling UA <- SPS > 200 OK > > Calling UA -> SPS > ACK > > SPS -> Called UA > ACK Here, the call will be setup without Session Timer even though the SPS wanted one and the UAC could do the necessary re-inviting. The UAS doesn't need to know about Session Timers in order to process re-INVITEs properly. The only thing that forces that the UAS have to be aware of the Session Timer is the statement in the draft that the UAS SHOULD send BYE if no re-INVITE has arrived when the session expires. Well, the UAC could do the sending of the BYE if it does not intend to update the timer. So, to solve this problem, I would like to propose that the SPS could add a Session-Expires header in the response if the SPS knows the UAC supports 'timer' and the response does not contain a Session-Expires header. Another similar situation occurs when the UAC does not support 'timer' but the UAS does. Then, according to the draft, the SPS MUST NOT add a Session-Expires header. If the SPS were allowed to add such a header also in this case, the UAS could do the refreshes and the 'timer' would be applied. The UAS would simply look at the Supported header, if present. If the request states support for timer, the UAS knows the UAC does the re-inviting, otherwise the UAS will do it. A useful semantic that the proxy can signal with this proposal is "I'm giving you a service here, but only for a limited period of time if you do not request to refresh the service". As opposed to the current draft that limits the SPS expressivness to "I require that you support session timer to get my service" or "Please, use the session timer". Apologies if I have missed something fundamental. /Lars -- Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 10:21:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05915 for ; Tue, 16 May 2000 10:21:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B921444383; Tue, 16 May 2000 10:14:06 -0400 (EDT) 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 0216744377 for ; Tue, 16 May 2000 10:14:03 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Tue, 16 May 2000 09:09:17 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 May 2000 09:07:06 -0500 Message-ID: From: "Glenn Morrow" To: sip Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Tue, 16 May 2000 09:07:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBF40.03D8172E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFBF40.03D8172E Content-Type: text/plain I don't believe people are opposed to the proposal by the security task force for the basic public infrastructure. I believe the concern is the verbage wanting to get rid of support for the other methods of security such as a separate encryption of headers and values at the application level. The primary reason I see for this back-pressure being that the trust model only goes so far for certain types of organizations and individuals. Please take a look at say a STU-III terminal and it's requirements. To remove these built-in mechanisms would undermine a rather significant advantage of SIP over other signaling methods. Respectfully, Glenn ++++++++++++++++++++++++++++ The problem with having 25 mechanisms for security is that the probability of being able to build a secure system goes down because different vendors make different choices and thus we get non-interoperability and even the probability of having any solution implemented in a given instance goes down. I would prefer to see one less than perfect solution that works most of the time then 25 solutions, each perfect for one kind of system. The existing mechanisms aren't close to good enough for such a status. There are already too many options. I don't really care what mechanism we choose as as long as we pick one, and then really work towards getting everyone to implement it. The present situation, which AFAIK there a precious few implementations, and does not provide an adequate level of security, is not satisfactory. Augmenting it with lots more alternatives is not satisfactory. Brian ------_=_NextPart_001_01BFBF40.03D8172E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] Minutes of SIP Security task force in Adelaide

I don't believe = people are opposed to the proposal by the security task force for the = basic public infrastructure.

I believe the = concern is the verbage wanting to get rid of support for the other = methods of security such as a separate encryption of headers and values = at the application level.

The primary reason I = see for this back-pressure being that the trust model only goes so far = for certain types of organizations and individuals. Please take a look = at say a STU-III terminal and it's requirements.

To remove these = built-in mechanisms would undermine a rather significant advantage of = SIP over other signaling methods.

Respectfully,

Glenn

++++++++++++++++++++++++++++

The problem with = having 25 mechanisms for security is that the probability of
being able to build = a secure system goes down because different vendors make different = choices and thus we get non-interoperability and even the probability = of having any

solution implemented = in a given instance goes down.
 
I would prefer to = see one less than perfect solution that works most of the time
then 25 solutions, = each perfect for one kind of system.   The existing = mechanisms
aren't close to = good enough for such a status.  There are already too many = options.
 
I don't really care = what mechanism we choose as as long as we pick one,
and then really = work towards getting everyone to implement it.  The present = situation,
which AFAIK there a = precious few implementations, and does not provide an adequate
level of security, = is not satisfactory.  Augmenting it with lots more alternatives is = not=20
satisfactory.
 
Brian



------_=_NextPart_001_01BFBF40.03D8172E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 11:11:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06832 for ; Tue, 16 May 2000 11:11:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 940EA44392; Tue, 16 May 2000 11:04:40 -0400 (EDT) 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 B304944391 for ; Tue, 16 May 2000 11:04:37 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA19762; Tue, 16 May 2000 08:11:48 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA25591; Tue, 16 May 2000 08:11:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14625.25900.977195.346906@thomasm-u1.cisco.com> Date: Tue, 16 May 2000 08:11:40 -0700 (PDT) To: Cc: "Jonathan Rosenberg" , "Michael Thomas" , , "Giuseppe Ricagni" Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <200005161237.FAA13968@nasnfs.eng.sun.com> References: <200005161237.FAA13968@nasnfs.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf writes: > I don't think the analogy between SIP and HTTP is valid. I see it more > as being between SIP and routing. Suppose I would have to go all the > way back to my home network to get my packets routed. This is a pretty dubious analogy. We're talking about proxy-routed signaling traffic and that alone. You're making it sound like the media would do dog-leg routing through the home network which is absurd. > Even if you are willing to grant the analogy, HTTP requests nowadays often > don't get routed to the server that somebody set up as their web site. > If your ISP is concerned about service, they may have set up an Inktomi > cache, and if the publisher is concerned, they may have contracted with > Akami to do the same. So the world is not so simple as "let's make it > free and easy for anybody to set up service" on the Web anymore. You're assuming that every thing is going to be a gigantic commercial service. I disagree. It's still perfectly possible for me to run a web server at home, and in fact I do. We haven't engineered walls around that possibility. Requiring that I use a foreign proxy does, or at least thinks it does. Also: you're talking about transparent caching, not proxying in the web case. I've not heard of any ISP that *require* that I go through their HTTP proxies. > You can > set up your service, but unless you have a concerned ISP or the money > to pay Akami, the latency in using your service may cause people to > go elsewhere. This analogy is fatally flawed. Cache's are great for the mountains of .gif's. There aren't similar considerations for SIP. Also: even if you're talking about co-lo servers distributed geographically, the site owner still "owns" the site. What you're talking about here is something run by their *competition* on your subscriber's behalf. Yuck. > I know this isn't going to be a popular viewpoint, but I think we need > to be realistic about the design. SIP already contains support for > telling an incoming caller that a client has moved, I can't see the > harm in using a remote proxy, given the performance concerns. I think we have to demonstrate that there are legitimate performance concerns before we solve for them. Sanity check: we're talking about a hypothetical case where the SIP UA is in the handset, right? We're not talking about the case where you're terminating SIP at the next logical hop up (BTS, MSC) for legacy, right? I'm talking about the former. In the latter, its debatable which proxy should do routing. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 11:31:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07295 for ; Tue, 16 May 2000 11:31:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2A0244391; Tue, 16 May 2000 11:23:38 -0400 (EDT) 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 33F6A4438A for ; Tue, 16 May 2000 11:23:36 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA28034; Tue, 16 May 2000 08:30:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA25594; Tue, 16 May 2000 08:30:27 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14625.27027.398470.130070@thomasm-u1.cisco.com> Date: Tue, 16 May 2000 08:30:27 -0700 (PDT) To: "Ashutosh Dutta" Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <852568E1.00456034.00@notes949.cc.telcordia.com> References: <852568E1.00456034.00@notes949.cc.telcordia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ashutosh Dutta writes: > As far as whether to talk to the home proxy or local proxy, for a wireless > roaming user which is changing domains frequently during mid-session-call and > is on the move, it may be better to talk to the local proxy rather than going to > the home proxy all the way during every hand-off (for latency reason I guess), > of course there needs to be a security association between the local-proxy and > home proxy or via public-proxy. This is one of the things we were trying to > debate during SIP-2000 conference in Paris last week to see the trade-off > between either talking to home-proxy or local domain proxy during frequent > hand-off, then there is also a possibility of interaction between local SIP > server and AAA server for a roaming user's profile verification during domain > handoff. Again, sanity check: are we talking about a SIP UA in the handset? If so, I don't see why an established call needs to go through *any* proxy. Handing off is a matter of reestablishing base level (IP) connectivity which means AAA to the local provider and probably some RSVP futzing to do the media handoff. If we're talking about SIP'ed legacy handoff, we're talking about UA to UA handoff, not proxy to proxy. As I said in previous mail, it's less clear to me which is better in that case. Feature transparency may be better if you route it through your home proxy, but you still have a fundamental problem with discordant UA/Proxies and the general database problem. This is *not* a problem for the UA in the handset though; introducing a foreign proxy takes us right back to that feature transparency problem, which to me seems like a huge mistake. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 12:01:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08146 for ; Tue, 16 May 2000 12:01:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3DED443BB; Tue, 16 May 2000 11:54:22 -0400 (EDT) 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 D9CC2443BA for ; Tue, 16 May 2000 11:54:19 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Tue, 16 May 2000 10:58:21 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 May 2000 11:01:10 -0500 Message-ID: From: "Glenn Morrow" To: sip Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Tue, 16 May 2000 11:01:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBF4F.F2B1408C" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFBF4F.F2B1408C Content-Type: text/plain; charset="ISO-8859-1" Below > > Glenn Morrow wrote: > > > > > Jonathan Rosenberg opened the discussion by suggesting that: > > > - SIP encryption (not authentication) should be deprecated, > > because: > > > > I strongly disagree with this. SIP encryption serves a number of > > useful > > purposes. It hides information, for example, about Contact, > > Subject, > > Organization, Retry-After, media types, media IP addresses and > > meeting > > times (in SDP), SDP k= keys, etc. All of these are irrelevant for > > proxy > > routing behavior, but highly sensitive. > > > > I agree with the disagreement. > > There isn't really any disagreement. I made this obviously bold > statement as an expression of my concerns with relying on end to end as > the sole mechanism for privacy. In the end, we did agree that it should > stay. > Wunderbar! Thanks for the clarification. > > > > > o It doesn't work with NAT and firewalls > > > > That's a risk you take. I refuse to dumb down protocols for > > everybody > > just because some people are behind firewalls and NATs. There are > > lots > > of protocols or features that you can't use behind a firewall or > > NAT. > > > > One could consider a SIP proxy as an ALG and a firewall element, > > could one not? If you agree with this then it does work for NAT > > and firewalls. > > No, this does *not* work. The body of the SIP message is encrypted with > the public key of the target in the To field. This is therefore not > readable by anyone except the recipient, which means that NAT, > co-located with a proxy or otherwise, can't see it. Normal proxies don't > need to see it, but an ALG does. Thats why SIP doesn't work through NATs > when encrypted. But, hop by hop does work, since the proxy can decrypt > the message. > I definitely agree if we are talking about a NAT-PT/ALG that is trying to be a SIP firewall/proxy as well. Do you agree that a NAT that is not concerned with the port i.e. a simple NAT/firewall for security, denial of service, etc.. would have a problem with this method if indeed there was a protected SIP proxy behind the NAT/firewall? Sorry again - there are so many forms of NAT/proxy/firewall and different uses for each. > Anyway, I believe there are uses for e2e encryption. Like everything > else in engineering, its a tradeoff. Go for top notch security, and you > get no services. > While I might be mis-interpreting something, it appears to me that you can have just as many services with e2e encryption; however, these services must be provided by the hosts and network entitities that are supposed to provide and protect the services. Services are worth money and providers distinguish themselves with services. SIP e2e encryption allows services to be protected at the application level while allowing certain proxy functions that are necessary for hop by hop routing through say a public infrastructure. You can't do that with other standardized session signaling protocols that I'm aware of. Anyone, I'm pretty much done with this thread. Don't want to waste people's time including my own. I hope we can agree on the value of the functionality. Thanks for the clarifications, etc.. Glenn > -Jonathan R. > > > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFBF4F.F2B1408C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Minutes of SIP Security task force in Adelaide

    Below


    > Glenn Morrow wrote:
    >
    >      = > Jonathan Rosenberg opened the discussion by suggesting = that:
    >      = > - SIP encryption (not authentication) should be deprecated,
    >      = because:
    >
    >      I = strongly disagree with this. SIP encryption serves a number of
    >      = useful
    >      = purposes. It hides information, for example, about Contact,
    >      = Subject,
    >      = Organization, Retry-After, media types, media IP addresses and
    >      = meeting
    >      = times (in SDP), SDP k=3D keys, etc. All of these are irrelevant = for
    >      = proxy
    >      = routing behavior, but highly sensitive.
    >
    >      I = agree with the disagreement.

    There isn't really any disagreement. I = made this obviously bold
    statement as an expression of my = concerns with relying on end to end as
    the sole mechanism for privacy. In = the end, we did agree that it should
    stay.
     
    Wunderbar! Thanks = for the clarification.

    >
    >      = >   o It doesn't work with NAT and firewalls
    >
    >      = That's a risk you take. I refuse to dumb down protocols for
    >      = everybody
    >      = just because some people are behind firewalls and NATs. There = are
    >      = lots
    >      of = protocols or features that you can't use behind a firewall or
    >      = NAT.
    >
    >      = One could consider a SIP proxy as an ALG and a firewall element,
    >      = could one not? If you agree with this then it does work for NAT
    >      = and firewalls.

    No, this does *not* work. The body of = the SIP message is encrypted with
    the public key of the target in the = To field. This is therefore not
    readable by anyone except the = recipient, which means that NAT,
    co-located with a proxy or otherwise, = can't see it. Normal proxies don't
    need to see it, but an ALG does. = Thats why SIP doesn't work through NATs
    when encrypted. But, hop by hop does = work, since the proxy can decrypt
    the message.

    I definitely agree = if we are talking about a NAT-PT/ALG that is trying to be a SIP = firewall/proxy as well.

    Do you agree that a = NAT that is not concerned with the port i.e. a simple NAT/firewall for = security, denial of service, etc.. would have a problem with this = method if indeed there was a protected SIP proxy behind the = NAT/firewall?

    Sorry again - there = are so many forms of NAT/proxy/firewall and different uses for = each.=20

    Anyway, I believe there are uses for = e2e encryption. Like everything
    else in engineering, its a tradeoff. = Go for top notch security, and you
    get no services.

    While I might be = mis-interpreting something, it appears to me that you can have just as = many services with e2e encryption; however, these services must be = provided by the hosts and network entitities that are supposed to = provide and protect the services. Services are worth money and = providers distinguish themselves with services.

    SIP e2e encryption = allows services to be protected at the application level while allowing = certain proxy functions that are necessary for hop by hop routing = through say a public infrastructure.

    You can't do that = with other standardized session signaling protocols that I'm aware = of.

    Anyone, I'm pretty = much done with this thread. Don't want to waste people's time including = my own. I hope we can agree on the value of the = functionality.


    Thanks for the = clarifications, etc..

    Glenn


    -Jonathan R.




    --
    Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
    Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
    dynamicsoft       &nbs= p;           &nbs= p;           &nbs= p; East Hanover, NJ 07936
    jdrosen@dynamicsoft.com     &nbs= p;           &nbs= p;   FAX:   (732) 741-4778
    http://www.cs.columbia.edu/~jdrosen         PHONE: = (732) 741-7244
    http://www.dynamicsoft.com


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

------_=_NextPart_001_01BFBF4F.F2B1408C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 16:51:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12357 for ; Tue, 16 May 2000 16:51:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2EEA24434C; Tue, 16 May 2000 16:44:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blanc.cisco.com (blanc.cisco.com [161.44.3.203]) by lists.bell-labs.com (Postfix) with ESMTP id 036B24433D for ; Tue, 16 May 2000 16:43:56 -0400 (EDT) Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id QAA19770; Tue, 16 May 2000 16:50:32 -0400 (EDT) From: David Daiker Message-Id: <200005162050.QAA19770@blanc.cisco.com> Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Tue, 16 May 2000 16:50:23 -0400 (EDT) Cc: mat@cisco.com (Michael Thomas), giuseppe.ricagni@italtel.it (Giuseppe Ricagni), James.Kempf@Eng.Sun.COM (James Kempf), sip@lists.bell-labs.com In-Reply-To: <392080EB.5047280@dynamicsoft.com> from "Jonathan Rosenberg" at May 15, 2000 06:57:47 PM X-Mailer: ELM [version 2.5 PL1] 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > > * some people claim the "proxy" should also perform some kind of admission > > > control for the calls. The proxy in the home domain has no information on the > > > visited domain > > > > This is true of the foreign domain too. How does > > any proxy have knowledge of network topology? > > Call admission control in proxies >>will never work<<. As Mike suggests, > this belongs in the transport layer, not the signaling layer. > > -Jonathan R. > -- Doesn't a proxy do this everytime it returns a 401 or 407 response to an INVITE ? Isn't PacketCable DCS doing this also ? How about h.323 ? are you suggesting that if I am visiting China, and make calls from a h.323 endpoint I can forward admission and location requests to my favorite gatekeeper back in the States ? I'm obviously missing something... david _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 16:57:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12449 for ; Tue, 16 May 2000 16:57:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B3E934439F; Tue, 16 May 2000 16:49:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 194E244396 for ; Tue, 16 May 2000 16:49:53 -0400 (EDT) Received: from dynamicsoft.com (1Cust76.tnt2.freehold.nj.da.uu.net [63.17.114.76]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA24839; Tue, 16 May 2000 16:58:07 -0400 (EDT) Message-ID: <3921B8D1.46BD94B6@dynamicsoft.com> Date: Tue, 16 May 2000 17:08:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Daiker Cc: Michael Thomas , Giuseppe Ricagni , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005162050.QAA19770@blanc.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit David Daiker wrote: > > > > > * some people claim the "proxy" should also perform some kind of admission > > > > control for the calls. The proxy in the home domain has no information on the > > > > visited domain > > > > > > This is true of the foreign domain too. How does > > > any proxy have knowledge of network topology? > > > > Call admission control in proxies >>will never work<<. As Mike suggests, > > this belongs in the transport layer, not the signaling layer. > > > > -Jonathan R. > > -- > > Doesn't a proxy do this everytime it returns a 401 or 407 response > to an INVITE ? Um, no. Proxies generate 407s to authenticate users to SIP resources, not perform admission control based on QoS for the media path. > > Isn't PacketCable DCS doing this also ? No. The admission control for RSVP is still done in the media path. It is only policy based authorization that is done in the proxy, and this authorization is passed to the gate performing QoS admission control. > > How about h.323 ? are you suggesting that if I am visiting China, > and make calls from a h.323 endpoint I can forward admission and location > requests to my favorite gatekeeper back in the States ? No. I am saying no proxy can usefully make admission control decisions based on bandwidth, QoS, or media path resource availability. This holds for the proxy in China and in the US. They can, of course, make "admission control" decisions about access to resources they actually provide, such as SIP features. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 16 17:12:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12629 for ; Tue, 16 May 2000 17:12:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E644D443B3; Tue, 16 May 2000 17:04:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 88C4C4433D for ; Tue, 16 May 2000 17:04:38 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id XAA10476 for ; Tue, 16 May 2000 23:10:32 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id XAA19803 for ; Tue, 16 May 2000 23:09:14 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id XAA07701 for ; Tue, 16 May 2000 23:09:34 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA4C4D; Tue, 16 May 2000 23:19:27 +0200 Message-ID: <39216923.37622CD3@italtel.it> Date: Tue, 16 May 2000 17:28:35 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, Michael: > > > > Giuseppe Ricagni writes: > > > * possible optimizations (e.g.: signalling for a basic call to an Australian > > > fixed network number from an Italian mobile roaming to Australia could be > > > processed locally, without any "tromboning") > > > > If during call setup there needs to be a round > > trip to the home network, it pretty much negates > > any advantage of proxying the call locally. > > Please note that this service (optimized dial plans based on roaming) is > still possible even if I go directly to the home network. All I need to > do is indicate to my home proxy where I am, so it knows what dial plan > to apply. In fact, dial plan administration is, in general, a service > that can be outsourced to any ASP (of course, only local ASPs may wish > to provide it, but the point is anyone can). > I was just talking about the PDD (post dial delay) for a call that can be processed locally, without any kind of message sent to the home network. Morever, if we start from the assumption (for the above mentioned reasons) that all SIP signalling goes through at least one proxy, the advantages of having a local proxy is relevant for example in case of (SIP, hard) handovers (I' m always referring to Henning' s approach to SIP mobility). The reduced RTT results in a much smaller number of lost packets. Giuseppe -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 18:50:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13825 for ; Tue, 16 May 2000 18:50:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A5A044377; Tue, 16 May 2000 18:43:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id 2D9BF4433D for ; Tue, 16 May 2000 18:43:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26826; Tue, 16 May 2000 16:23:17 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA03344; Tue, 16 May 2000 15:23:05 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA05644; Tue, 16 May 2000 15:22:23 -0700 (PDT) From: James Kempf Message-Id: <200005162222.PAA05644@nasnfs.eng.sun.com> Date: Tue, 16 May 2000 15:25:02 -0700 To: "Michael Thomas" , Cc: "Giuseppe Ricagni" , , "Michael Thomas" , "Jonathan Rosenberg" Reply-To: Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >James Kempf writes: > > I don't think the analogy between SIP and HTTP is valid. I see it more > > as being between SIP and routing. Suppose I would have to go all the > > way back to my home network to get my packets routed. > > This is a pretty dubious analogy. We're talking > about proxy-routed signaling traffic and that > alone. You're making it sound like the media > would do dog-leg routing through the home > network which is absurd. > No, that's not what I meant. Thhe point I was trying to make is that I don't think people will be very happy if it takes them substantially longer to make a telephone connection remotely than it does at home. It can take somewhat longer (as it does today in the circuit switched world) but not *substantially* longer. I don't have the numbers for intercontinental routing delays in my head but I can believe they must be more than routing delays to a local ISP. Whether those delays will, in fact, be substantial enough to merit having local proxies is a matter that can be solved by engineering analysis (and not political posturing, as this thread seems to have degenerated into). > > Even if you are willing to grant the analogy, HTTP requests nowadays often > > don't get routed to the server that somebody set up as their web site. > > If your ISP is concerned about service, they may have set up an Inktomi > > cache, and if the publisher is concerned, they may have contracted with > > Akami to do the same. So the world is not so simple as "let's make it > > free and easy for anybody to set up service" on the Web anymore. > > You're assuming that every thing is going to > be a gigantic commercial service. I disagree. > It's still perfectly possible for me to run a > web server at home, and in fact I do. We > haven't engineered walls around that > possibility. Requiring that I use a foreign > proxy does, or at least thinks it does. > Your web server at home is leveraging off the fact that a company, probably AT&T back when they had a monopoly, strung a wire to your house and installed switching equipment at the local office. They made the infrastructue investment years ago that now allows you and your ISP to offer service really cheaply. You may be limited as to the bandwidth you get, due to the fact that your current local telephone provider is not willing to make the infrastructure investment to upgrade to fiber. The UK government just auctioned off UMTS licenses for something like $25B (as in 1 with 9 zeros behind it). Anyone who is not able to come up with that kind of cash will have a hard time offering wireless telephony service. It will take years to amortize that kind of investment. Of course, there is always the unlicensed spectrum and I'm sure there will be players like Metricom who figure out creative ways to utilize it. > Also: you're talking about transparent caching, > not proxying in the web case. I've not heard > of any ISP that *require* that I go through > their HTTP proxies. > > > You can > > set up your service, but unless you have a concerned ISP or the money > > to pay Akami, the latency in using your service may cause people to > > go elsewhere. > > This analogy is fatally flawed. Cache's are > great for the mountains of .gif's. There aren't > similar considerations for SIP. Also: even > if you're talking about co-lo servers > distributed geographically, the site owner > still "owns" the site. What you're talking > about here is something run by their > *competition* on your subscriber's behalf. > > Yuck. > Cellular companies already have romaing agreements. There's nothing new about it. With regard to caches v.s. proxies, the only point I was trying to make was that customers want fast service. Whether that service is web page access or connecting for a telephone call. It therefore makes sense to engineer such that the service provider can provide that service, whether it requires transparent caches or local proxies. > > I know this isn't going to be a popular viewpoint, but I think we need > > to be realistic about the design. SIP already contains support for > > telling an incoming caller that a client has moved, I can't see the > > harm in using a remote proxy, given the performance concerns. > > I think we have to demonstrate that there > are legitimate performance concerns before we > solve for them. > Agreed. > Sanity check: we're talking about a > hypothetical case where the SIP UA is > in the handset, right? We're not talking > about the case where you're terminating SIP > at the next logical hop up (BTS, MSC) for > legacy, right? I'm talking about the former. > In the latter, its debatable which proxy > should do routing. > I was talking about both. The legacy situtation will be important for some time, particularly in the North American case where the 2G and 3G spectrum allocations overlap. But I think the core network design should be there for smooth transition to the SIP based handset. jak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 16 20:02:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14405 for ; Tue, 16 May 2000 20:02:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5FCD74433D; Tue, 16 May 2000 19:54:34 -0400 (EDT) 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 9B2D144337 for ; Tue, 16 May 2000 19:54:31 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA01332; Tue, 16 May 2000 17:01:48 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA25660; Tue, 16 May 2000 17:01:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14625.57701.124592.886488@thomasm-u1.cisco.com> Date: Tue, 16 May 2000 17:01:41 -0700 (PDT) To: Cc: "Michael Thomas" , "Giuseppe Ricagni" , , "Jonathan Rosenberg" Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <200005162222.PAA05644@nasnfs.eng.sun.com> References: <200005162222.PAA05644@nasnfs.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf writes: > No, that's not what I meant. Thhe point I was trying to make is that > I don't think people will be very happy if it takes them > substantially longer to make a telephone connection remotely than it > does at home. It can take somewhat longer (as it does today in the > circuit switched world) but not *substantially* longer. Question: isn't it the case that the roamed system needs to do a database dip on the home system to get their subscriber information? If so, even in the current situation, you have a round trip to the home system. This is why I'm extremely dubious that there is any substantial difference in call setup time. The same would be true in the scenario you propose: in order to proxy my service onto the roamed proxy, it would need to do some database dip back to my home proxy to find out my features. If I routed it through my home proxy, it looks like it would actually be *faster* because I'd only need to go through my home proxy rather than foreign-proxy->database-dip-at-home->routing. > I don't have > the numbers for intercontinental routing delays in my head but I can > believe they must be more than routing delays to a local ISP. Speed of light on fiber is about 20ms/1000miles as I recall. > Your web server at home is leveraging off the fact that a company, > probably AT&T back when they had a monopoly, strung a wire to your > house and installed switching equipment at the local office. They made the infrastructue > investment years ago that now allows you and your ISP to offer service > really cheaply. And I bow before New Jersey twice daily to give thanks to Bell above. > The UK government just auctioned off UMTS licenses for something like $25B > (as in 1 with 9 zeros behind it). Anyone who is not able to come up > with that kind of cash will have a hard time offering wireless > telephony service. It will take years to amortize that kind of investment. > Of course, there is always the unlicensed spectrum and I'm sure there > will be players like Metricom who figure out creative ways to utilize it. Oh, please. Let's keep track of where the actual investment is here: it's the air resources and the raw bandwidth it enables. There's an incremental delta for the switching equipment, but that's by and large the same equipment as landline. This doesn't seem very hard to me: if it's expensive to put bits in the air, then you charge for it. Let's not get taken down the path that the only viable business model for a bandwidth provider is to have monopoly access to the services I can access. That's the same mentality that didn't invent the Internet. The same Internet which dramatically demonstrates that there are other business models which can turn a tidy profit being a boring unintelligent network operator. If there are good engineering reasons, fine. But please lets not get sucked into bad engineering design driven by old world business models. > Cellular companies already have romaing agreements. There's nothing new about > it. I know they do, and my understanding is that feature transparency is one thing that suffers big time because of their current model. Keeping my features back where I get my features eliminates that feature synch problem at its root. That is impossible in the circuit switched world, but almost trivial in the SIP world. > > I think we have to demonstrate that there > > are legitimate performance concerns before we > > solve for them. > > > > Agreed. I think what might be useful rather than another round of impassioned polemics here is to see some message flows, paying particular attention to any hidden assumptions about what the home network needs to provide. 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 May 17 00:24:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18073 for ; Wed, 17 May 2000 00:24:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B3B614433B; Wed, 17 May 2000 00:17:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 10BA244337 for ; Wed, 17 May 2000 00:17:13 -0400 (EDT) Received: from dynamicsoft.com (1Cust76.tnt2.freehold.nj.da.uu.net [63.17.114.76]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA25660; Wed, 17 May 2000 00:25:26 -0400 (EDT) Message-ID: <392221A5.CB601993@dynamicsoft.com> Date: Wed, 17 May 2000 00:35:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Giuseppe Ricagni Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Giuseppe Ricagni wrote: > > Jonathan, Michael: > > > > > > Giuseppe Ricagni writes: > > > > * possible optimizations (e.g.: signalling for a basic call to an Australian > > > > fixed network number from an Italian mobile roaming to Australia could be > > > > processed locally, without any "tromboning") > > > > > > If during call setup there needs to be a round > > > trip to the home network, it pretty much negates > > > any advantage of proxying the call locally. > > > > Please note that this service (optimized dial plans based on roaming) is > > still possible even if I go directly to the home network. All I need to > > do is indicate to my home proxy where I am, so it knows what dial plan > > to apply. In fact, dial plan administration is, in general, a service > > that can be outsourced to any ASP (of course, only local ASPs may wish > > to provide it, but the point is anyone can). > > > > I was just talking about the PDD (post dial delay) for a call that can > be processed > locally, without any kind of message sent to the home network. I think the RTT for going to the home network is going to be a drop in the bucket compared to the typical PDDs in wireless today. The RTT for going to the home network is going to have to be reasonable to carry voice anyway, so we are talking a few hundred milliseconds, worst case? It takes my cell phone 5 seconds for PDD now.... > > Morever, if we start from the assumption (for the above mentioned > reasons) that all SIP > signalling goes through at least one proxy, the advantages of having a > local proxy is > relevant for example in case of (SIP, hard) handovers (I' m always > referring to Henning' s approach to SIP mobility). The reduced RTT > results in a much smaller number of lost packets. How is that? Its a dangerous game to make strong assumptions on loss models like this. In any case, I think that optimizing an architecture based on assumptions about loss distributions and latency is somewhat short-sighted. Lousy network quality is going to kill you on the compressed voice traffic long before the signaling gets really blown away. Even from a human factors perspective, most people will tolerate long PDDs but not high voice packet loss rates. If the signaling loss is really bothering you, deploy good networks with diffserv giving great service to port 5060. Eventually these network performance problems will get solved. But, fundamental architectural decisions don't get changed. The ability to choose anyone as my applications provider, and not suffer horrible voice quality (since the audio always goes direct) is such a huge win for competition and service innovation. Saying no to that to save 50ms on signaling latency seems such a shame. This was my point about web. If I had to *rely* on my ISP replicating the content in order to fetch it, there never would have been a web. It is only because anyone, anywhere on the Internet could set up shop, and anyone, anywhere could access it, that we had the huge growth in this service. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 17 01:42:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23307 for ; Wed, 17 May 2000 01:42:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6AFD84433F; Wed, 17 May 2000 01:35:27 -0400 (EDT) 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 851B144337 for ; Wed, 17 May 2000 01:35:24 -0400 (EDT) Received: from dwillis (dwillis5.directlink.net [63.64.250.86]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id LAA06663; Wed, 17 May 2000 11:44:30 -0500 From: "Dean Willis" To: "James Kempf" Cc: Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Wed, 17 May 2000 00:41:44 -0500 Message-ID: <027201bfbfc2$95ad81c0$56fa403f@directlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2615.200 Importance: Normal In-Reply-To: <200005140219.TAA19786@nasnfs.eng.sun.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA23307 But what if your speed-dial list and your find-others scripts and your automatically-included features like recording and transcription are activated by your home proxy? Personally, I plan to use the custom services I've built around my environment even when I'm roaming, and I plan to build many of those services into my home proxy. -- Dean > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of James Kempf > Sent: Saturday, May 13, 2000 9:22 PM > To: James.Kempf@Eng.Sun.COM; mat@cisco.com > Cc: sip@lists.bell-labs.com; jdrosen@dynamicsoft.com > Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide > > > > > > Certainly in the case of cellular, it will be the case that the > > > proxy will be changing. When the mobile terminal roams outside > > > of it's cellular provider's domain, the new proxy needs to be > authenticated > > > with the mobile terminal, and vice versa. > > > > That sort of pre-supposes that the proxy the > > handset contacts when it's roamed isn't its > > home proxy. I'm not sure I see why that > > wouldn't still be the case. I hope people > > aren't getting buffaloed into some garden > > walls kind of mentality where the service > > provider gets to keep their stranglehold on > > services. > > > > It's not the case because if I have my cellular account with a provider > in California and I travel to Australia, I don't want to have to > go all the way back to the SIP proxy with my provider in California > to have to make a call. > > > jak > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Wed May 17 02:02:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27614 for ; Wed, 17 May 2000 02:02:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01CE044341; Wed, 17 May 2000 01:55:27 -0400 (EDT) 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 1D92B44340 for ; Wed, 17 May 2000 01:55:25 -0400 (EDT) Received: from dwillis (dwillis5.directlink.net [63.64.250.86]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id MAA06704; Wed, 17 May 2000 12:04:39 -0500 From: "Dean Willis" To: "Jonathan Rosenberg" Cc: "IETF SIP" Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Wed, 17 May 2000 01:01:52 -0500 Message-ID: <027401bfbfc5$65c90a80$56fa403f@directlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2615.200 Importance: Normal In-Reply-To: <3921B8D1.46BD94B6@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA27614 Jonathan wrote: > No. I am saying no proxy can usefully make admission control decisions > based on bandwidth, QoS, or media path resource availability. This holds > for the proxy in China and in the US. They can, of course, make > "admission control" decisions about access to resources they actually > provide, such as SIP features. Actually, I think there might be an exception. Let's say we have a large network that mixes several DiffServe classes -- for simplicity, let's say "best effort" and "priority" clases. Assume that there is normally a relatively high ratio of best-effort to priority traffic in the network. One might a heuristic for traffic engineering that works like this: Assume a network monitoring system that can provide both a rough estimate of the ration of best-effort to priority traffic on the backbone and on specific links. Feed this data into access proxies. Define a minimum ratio for both of those metrics, say 2-1. A proxy could then provide a "network health guidance" effect for edge devices. Sure, we can't KEEP an unfriendly app from jumping in during a peak congestion period, but we could certainly ADVISE friendly apps that it woudn't be a good idea to send more traffic right now. Or one could just put the QoS function under control of the proxy, which activates the last clause in Jonathan's argument. -- Dean -- Dean ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Wed May 17 02:27:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00345 for ; Wed, 17 May 2000 02:27:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA5C344354; Wed, 17 May 2000 02:20:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id AE3E044337 for ; Wed, 17 May 2000 02:20:27 -0400 (EDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4H6RdH00077 for ; Wed, 17 May 2000 08:27:39 +0200 (MET DST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FUO00K01XY2T7@mbb1.ericsson.se> for sip@lists.bell-labs.com; Wed, 17 May 2000 08:27:38 +0200 (MET DST) Received: from ericsson.com (kipe194.eraj.ericsson.se [147.214.68.194]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FUO00GH7XY20Q@mbb1.ericsson.se>; Wed, 17 May 2000 08:27:38 +0200 (MET DST) Date: Wed, 17 May 2000 08:26:55 +0200 From: Stephen Terrill Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide To: James.Kempf@Eng.Sun.COM Cc: Michael Thomas , Giuseppe Ricagni , sip@lists.bell-labs.com, Jonathan Rosenberg Reply-To: stephen.terrill@era.ericsson.se Message-id: <39223BAF.DBA2A87D@ericsson.com> Organization: L.M. Ericsson MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win98; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <200005162222.PAA05644@nasnfs.eng.sun.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8BIT Hi James, I think that the emphansis on saving the trombing of the user signalling is much overweighted. Firstly, the "singlling" transport in these networks is not limited to the 64kbs singnalling channels used in the PSTN today. Secondly, even today, it is not uncommon for two operators in the same country (ie a european country) to interconnect to each other by going through the US due to commercial reasons (ie a call from one phone to another phone just 30 meeters away can cross the atlantic twice). What I am saying as that this happens today, and that is both user signalling and payload, and customer usually aren´t aware of it. As such, I do tend to agree with Jonathan and Mike that the advantages of taking the call/session signalling to the "home" proxy outweigh this small and dissappearing disadvantage. Regards, ..//steve James Kempf wrote: > >James Kempf writes: > > > I don't think the analogy between SIP and HTTP is valid. I see it more > > > as being between SIP and routing. Suppose I would have to go all the > > > way back to my home network to get my packets routed. > > > > This is a pretty dubious analogy. We're talking > > about proxy-routed signaling traffic and that > > alone. You're making it sound like the media > > would do dog-leg routing through the home > > network which is absurd. > > > > No, that's not what I meant. Thhe point I was trying to make is that > I don't think people will be very happy if it takes them > substantially longer to make a telephone connection remotely than it > does at home. It can take somewhat longer (as it does today in the > circuit switched world) but not *substantially* longer. I don't have > the numbers for intercontinental routing delays in my head but I can > believe they must be more than routing delays to a local ISP. Whether > those delays will, in fact, be substantial enough to merit having > local proxies is a matter that can be solved by engineering analysis > (and not political posturing, as this thread seems to have degenerated into). > > > > Even if you are willing to grant the analogy, HTTP requests nowadays often > > > don't get routed to the server that somebody set up as their web site. > > > If your ISP is concerned about service, they may have set up an Inktomi > > > cache, and if the publisher is concerned, they may have contracted with > > > Akami to do the same. So the world is not so simple as "let's make it > > > free and easy for anybody to set up service" on the Web anymore. > > > > You're assuming that every thing is going to > > be a gigantic commercial service. I disagree. > > It's still perfectly possible for me to run a > > web server at home, and in fact I do. We > > haven't engineered walls around that > > possibility. Requiring that I use a foreign > > proxy does, or at least thinks it does. > > > > Your web server at home is leveraging off the fact that a company, > probably AT&T back when they had a monopoly, strung a wire to your > house and installed switching equipment at the local office. They made the infrastructue > investment years ago that now allows you and your ISP to offer service > really cheaply. You may be limited as to the bandwidth you get, due > to the fact that your current local telephone provider is not willing > to make the infrastructure investment to upgrade to fiber. > > The UK government just auctioned off UMTS licenses for something like $25B > (as in 1 with 9 zeros behind it). Anyone who is not able to come up > with that kind of cash will have a hard time offering wireless > telephony service. It will take years to amortize that kind of investment. > Of course, there is always the unlicensed spectrum and I'm sure there > will be players like Metricom who figure out creative ways to utilize it. > > > Also: you're talking about transparent caching, > > not proxying in the web case. I've not heard > > of any ISP that *require* that I go through > > their HTTP proxies. > > > > > You can > > > set up your service, but unless you have a concerned ISP or the money > > > to pay Akami, the latency in using your service may cause people to > > > go elsewhere. > > > > This analogy is fatally flawed. Cache's are > > great for the mountains of .gif's. There aren't > > similar considerations for SIP. Also: even > > if you're talking about co-lo servers > > distributed geographically, the site owner > > still "owns" the site. What you're talking > > about here is something run by their > > *competition* on your subscriber's behalf. > > > > Yuck. > > > > Cellular companies already have romaing agreements. There's nothing new about > it. > > With regard to caches v.s. proxies, the only point I was trying to make was > that customers want fast service. Whether that service is web page access > or connecting for a telephone call. It therefore makes sense to engineer > such that the service provider can provide that service, whether it requires > transparent caches or local proxies. > > > > I know this isn't going to be a popular viewpoint, but I think we need > > > to be realistic about the design. SIP already contains support for > > > telling an incoming caller that a client has moved, I can't see the > > > harm in using a remote proxy, given the performance concerns. > > > > I think we have to demonstrate that there > > are legitimate performance concerns before we > > solve for them. > > > > Agreed. > > > Sanity check: we're talking about a > > hypothetical case where the SIP UA is > > in the handset, right? We're not talking > > about the case where you're terminating SIP > > at the next logical hop up (BTS, MSC) for > > legacy, right? I'm talking about the former. > > In the latter, its debatable which proxy > > should do routing. > > > > I was talking about both. The legacy situtation will be important for > some time, particularly in the North American case where the 2G and > 3G spectrum allocations overlap. But I think the core network design > should be there for smooth transition to the SIP based handset. > > jak > > _______________________________________________ > 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 May 17 03:49:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00926 for ; Wed, 17 May 2000 03:49:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA25744349; Wed, 17 May 2000 03:41:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 333F444337 for ; Wed, 17 May 2000 03:41:55 -0400 (EDT) Received: by EXCHANGESVR with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 00:49:25 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: IETF SIP Date: Wed, 17 May 2000 00:49:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Error response to re-INVITE. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com When a UAS issues a 400+ response to a re-INVITE, is it signaling that a) the entire call has been torn down or b) that only the re-INVITE failed but the call is still active? I couldn't find anywhere this has been clarified. Both scenarios have their uses and pitfalls. The former case allows no room for correction/negotiation of the failed message component. Problems also arise if one side or one of the intermediate proxies assumes that the call has not been torn down. Likewise, if the latter alternative is true, then it is easily conceivable that a UAC might incorrectly issue an ACK instead of a BYE to the failed re-INVITE. Now the UAC has torn down the call but the UAS has not. I guess you could say that this is simply another reason why the SIP Session Timer is a good idea. Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 04:06:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01093 for ; Wed, 17 May 2000 04:06:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 560444435A; Wed, 17 May 2000 03:59:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id CFECB44359 for ; Wed, 17 May 2000 03:57:37 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA08620; Wed, 17 May 2000 14:15:21 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568E2.002D036B ; Wed, 17 May 2000 13:41:39 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Fairlie-Cuninghame, Robert" Cc: IETF SIP Message-ID: <652568E2.002D01D1.00@sampark.hss.hns.com> Date: Wed, 17 May 2000 13:41:35 +0530 Subject: Re: [SIP] Error response to re-INVITE. 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, The current understanding is that if a RE-INVITE fails - its valid only for the reinvite and not for the entire call. i.e. the previous call parameters (and hence the call) are still active. robert> Likewise, if the latter alternative is true, then it is easily conceivable robert> that a UAC might incorrectly issue an ACK instead of a BYE to the failed robert> re-INVITE. Now the UAC has torn down the call but the UAS has not. I dont follow you here. Why is this a problem ? the usual INVITE-FinalResponse-ACK happens here. Both parties know the RE-INVITE failed and hence the old call proceeds. The RE-INVITE issuing party as it is needs to send an ACK to the final response from the other party. And a BYE Iguess will be sent only if the calling party decides that if the re-INVITE fails, then he is not interested in carrying on with the old parameters. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Fairlie-Cuninghame, Robert" on 05/17/2000 01:19:17 PM To: IETF SIP cc: Subject: [SIP] Error response to re-INVITE. When a UAS issues a 400+ response to a re-INVITE, is it signaling that a) the entire call has been torn down or b) that only the re-INVITE failed but the call is still active? I couldn't find anywhere this has been clarified. Both scenarios have their uses and pitfalls. The former case allows no room for correction/negotiation of the failed message component. Problems also arise if one side or one of the intermediate proxies assumes that the call has not been torn down. Likewise, if the latter alternative is true, then it is easily conceivable that a UAC might incorrectly issue an ACK instead of a BYE to the failed re-INVITE. Now the UAC has torn down the call but the UAS has not. I guess you could say that this is simply another reason why the SIP Session Timer is a good idea. Cheers, Robert. _______________________________________________ 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 May 17 08:05:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03406 for ; Wed, 17 May 2000 08:05:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF7FA44340; Wed, 17 May 2000 07:57:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id E059C44337 for ; Wed, 17 May 2000 07:57:30 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14877; Wed, 17 May 2000 06:04:42 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA05687; Wed, 17 May 2000 05:04:41 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id FAA22241; Wed, 17 May 2000 05:03:57 -0700 (PDT) From: James Kempf Message-Id: <200005171203.FAA22241@nasnfs.eng.sun.com> Date: Wed, 17 May 2000 05:06:36 -0700 To: "Michael Thomas" , Cc: "Jonathan Rosenberg" , , "Giuseppe Ricagni" , "Michael Thomas" Reply-To: Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > Question: isn't it the case that the roamed > system needs to do a database dip on the > home system to get their subscriber > information? If so, even in the current > situation, you have a round trip to the home > system. This is why I'm extremely dubious that > there is any substantial difference in call > setup time. The same would be true in the scenario > you propose: in order to proxy my service onto > the roamed proxy, it would need to do some > database dip back to my home proxy to find out > my features. If I routed it through my home > proxy, it looks like it would actually be > *faster* because I'd only need to go through > my home proxy rather than > foreign-proxy->database-dip-at-home->routing. > With the proper security association, the subscriber profile could be forwarded to the roamed proxy, avoiding the round trip back to the home proxy. This actually would be a *big* saving from the current cellular networks, where the remote VLR has to go back to the HLR every time. I've seen some research work on this for current circuit switched, but it is crufty. It is lots easier to do it with an all IP network, provided the proper AAA protocols are in place. > > I don't have > > the numbers for intercontinental routing delays in my head but I can > > believe they must be more than routing delays to a local ISP. > > Speed of light on fiber is about 20ms/1000miles > as I recall. > That's transport. There's also routing. What's the queueing delay? > > Your web server at home is leveraging off the fact that a company, > > probably AT&T back when they had a monopoly, strung a wire to your > > house and installed switching equipment at the local office. They made the >infrastructue > > investment years ago that now allows you and your ISP to offer service > > really cheaply. > > And I bow before New Jersey twice daily > to give thanks to Bell above. > > > The UK government just auctioned off UMTS licenses for something like $25B > > (as in 1 with 9 zeros behind it). Anyone who is not able to come up > > with that kind of cash will have a hard time offering wireless > > telephony service. It will take years to amortize that kind of investment. > > Of course, there is always the unlicensed spectrum and I'm sure there > > will be players like Metricom who figure out creative ways to utilize it. > > Oh, please. Let's keep track of where the actual > investment is here: it's the air resources and > the raw bandwidth it enables. There's an > incremental delta for the switching equipment, > but that's by and large the same equipment as > landline. This doesn't seem very hard to me: > if it's expensive to put bits in the air, then > you charge for it. Let's not get taken down the > path that the only viable business model for a > bandwidth provider is to have monopoly access > to the services I can access. > It's not a monopoly, but there are very few companies in the world that are in the position to plunk down $5B or so for a UMTS license. And governments aren't offering many. It is partially the nature of the radio spectrum (too many users leads to interference) and partially business politics as usual. > That's the same mentality that didn't invent the > Internet. The same Internet which dramatically > demonstrates that there are other business > models which can turn a tidy profit being a > boring unintelligent network operator. If there > are good engineering reasons, fine. But > please lets not get sucked into bad engineering > design driven by old world business models. > > > Cellular companies already have romaing agreements. There's nothing new >about > > it. > > I know they do, and my understanding is that > feature transparency is one thing that suffers > big time because of their current model. > Keeping my features back where I get my > features eliminates that feature synch > problem at its root. That is impossible in > the circuit switched world, but almost trivial > in the SIP world. > If features can be easily forwarded between proxies (with the proper authentication) then it's even easier to get your features whereever you want them. > > > I think we have to demonstrate that there > > > are legitimate performance concerns before we > > > solve for them. > > > > > > > Agreed. > > I think what might be useful rather than another > round of impassioned polemics here is to see > some message flows, paying particular attention > to any hidden assumptions about what the home > network needs to provide. > Agreed! Putting numbers on message flows would answer the question. > Mike > > >_______________________________________________ >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 May 17 08:16:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03742 for ; Wed, 17 May 2000 08:16:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5745344353; Wed, 17 May 2000 08:08:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 1489344343 for ; Wed, 17 May 2000 08:08:52 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA01957; Wed, 17 May 2000 13:14:06 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sip Mail List Date: Wed, 17 May 2000 12:49:43 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00051713145204.06188@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] Problem with definition of In-Reply-To grammar Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit hi I have a problem with the In-Reply-To header, 2543 bis section 6.25 p. 48: "The In-Reply-To request header field enumerates the call-IDs that this call references or returns. This allows automatic call distribution systems to route return calls to the originator of the first call and allows callees to filter calls, so that only calls that return calls they have originated will be accepted. This field is not a substitute for request authentication. In-Reply-To = In-Reply-To : 1# callid" If i can refer you to Anders email titled: Re: [SIP] Another grammar query - Call-ID then callid has been re-defined as "Basically, the field should be treated as an opaque, uninterpreted identifier, e.g. TEXT-UTF8-TRIM in the grammar." The problem is that if the In-Reply-To header is: In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com then this will resolve as a single call-id not two separate ones. would it not be possible to say make call-id a quoted-string??? This may make little sense for the Call-ID header but it solves the problem here. what would we then compare on though? could escaped values get in here which would stop the efficient byte by byte equality checking that TEXT-UTF8-TRIM provided? cheers gethin -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@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 May 17 08:37:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04179 for ; Wed, 17 May 2000 08:37:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 39E8D44355; Wed, 17 May 2000 08:29:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 4D68844337 for ; Wed, 17 May 2000 08:29:43 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id OAA20784 for ; Wed, 17 May 2000 14:35:42 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id OAA02878 for ; Wed, 17 May 2000 14:34:23 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id OAA24688 for ; Wed, 17 May 2000 14:34:43 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA70E4; Wed, 17 May 2000 14:44:36 +0200 Message-ID: <392292D7.DD06C377@italtel.it> Date: Wed, 17 May 2000 14:38:47 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: stephen.terrill@era.ericsson.se Cc: James.Kempf@Eng.Sun.COM, Michael Thomas , sip@lists.bell-labs.com, Jonathan Rosenberg Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005162222.PAA05644@nasnfs.eng.sun.com> <39223BAF.DBA2A87D@ericsson.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Stephen, Stephen Terrill wrote: > Hi James, > > I think that the emphansis on saving the trombing of the user signalling is much overweighted. Firstly, the "singlling" transport in these networks is not limited to the 64kbs singnalling channels used in the PSTN today. Higher bandwidth doesn' t necessarily mean lower latency..... Moreover you don' t normally have *just one* 64Kb/s link. In this specific case, the tight delay requirements on SS7 networks, might well result in lower RTTs for signalling messages. > Secondly, even today, it is not uncommon for two operators in the same country (ie a european country) to interconnect to each other by going through the US due to commercial reasons (ie a call from one phone to another phone just 30 meeters away can cross the atlantic twice). What I am saying as that this happens today, and that is both user signalling and payload, and customer usually aren´t aware of it. > not saying that signalling should *always* be processed locally: as you know this is just impossible, especially when user profile data is required to process the call. What we are claiming here is that local procesing should be employed as an optimization, in all those cases where it is actually possible, without any (pre-call) data exchange with the home domain. > As such, I do tend to agree with Jonathan and Mike that the advantages of taking the call/session signalling to the "home" proxy outweigh this small and dissappearing disadvantage. I do tend to disagree... Why not applying an optimization (only in those cases where it can be applied, obviously) if it's easy, it has basically no disadvantages, and it can be even much more helpful in other contexts (seen my other posting ?) Cheers Giuseppe P.S. BTW: you will remember that “Optimised call routing” is a requirement for 3G networks (it does also refer to signalling).... > > > Regards, > > ..//steve > > James Kempf wrote: > > > >James Kempf writes: > > > > I don't think the analogy between SIP and HTTP is valid. I see it more > > > > as being between SIP and routing. Suppose I would have to go all the > > > > way back to my home network to get my packets routed. > > > > > > This is a pretty dubious analogy. We're talking > > > about proxy-routed signaling traffic and that > > > alone. You're making it sound like the media > > > would do dog-leg routing through the home > > > network which is absurd. > > > > > > > No, that's not what I meant. Thhe point I was trying to make is that > > I don't think people will be very happy if it takes them > > substantially longer to make a telephone connection remotely than it > > does at home. It can take somewhat longer (as it does today in the > > circuit switched world) but not *substantially* longer. I don't have > > the numbers for intercontinental routing delays in my head but I can > > believe they must be more than routing delays to a local ISP. Whether > > those delays will, in fact, be substantial enough to merit having > > local proxies is a matter that can be solved by engineering analysis > > (and not political posturing, as this thread seems to have degenerated into). > > > > > > Even if you are willing to grant the analogy, HTTP requests nowadays often > > > > don't get routed to the server that somebody set up as their web site. > > > > If your ISP is concerned about service, they may have set up an Inktomi > > > > cache, and if the publisher is concerned, they may have contracted with > > > > Akami to do the same. So the world is not so simple as "let's make it > > > > free and easy for anybody to set up service" on the Web anymore. > > > > > > You're assuming that every thing is going to > > > be a gigantic commercial service. I disagree. > > > It's still perfectly possible for me to run a > > > web server at home, and in fact I do. We > > > haven't engineered walls around that > > > possibility. Requiring that I use a foreign > > > proxy does, or at least thinks it does. > > > > > > > Your web server at home is leveraging off the fact that a company, > > probably AT&T back when they had a monopoly, strung a wire to your > > house and installed switching equipment at the local office. They made the infrastructue > > investment years ago that now allows you and your ISP to offer service > > really cheaply. You may be limited as to the bandwidth you get, due > > to the fact that your current local telephone provider is not willing > > to make the infrastructure investment to upgrade to fiber. > > > > The UK government just auctioned off UMTS licenses for something like $25B > > (as in 1 with 9 zeros behind it). Anyone who is not able to come up > > with that kind of cash will have a hard time offering wireless > > telephony service. It will take years to amortize that kind of investment. > > Of course, there is always the unlicensed spectrum and I'm sure there > > will be players like Metricom who figure out creative ways to utilize it. > > > > > Also: you're talking about transparent caching, > > > not proxying in the web case. I've not heard > > > of any ISP that *require* that I go through > > > their HTTP proxies. > > > > > > > You can > > > > set up your service, but unless you have a concerned ISP or the money > > > > to pay Akami, the latency in using your service may cause people to > > > > go elsewhere. > > > > > > This analogy is fatally flawed. Cache's are > > > great for the mountains of .gif's. There aren't > > > similar considerations for SIP. Also: even > > > if you're talking about co-lo servers > > > distributed geographically, the site owner > > > still "owns" the site. What you're talking > > > about here is something run by their > > > *competition* on your subscriber's behalf. > > > > > > Yuck. > > > > > > > Cellular companies already have romaing agreements. There's nothing new about > > it. > > > > With regard to caches v.s. proxies, the only point I was trying to make was > > that customers want fast service. Whether that service is web page access > > or connecting for a telephone call. It therefore makes sense to engineer > > such that the service provider can provide that service, whether it requires > > transparent caches or local proxies. > > > > > > I know this isn't going to be a popular viewpoint, but I think we need > > > > to be realistic about the design. SIP already contains support for > > > > telling an incoming caller that a client has moved, I can't see the > > > > harm in using a remote proxy, given the performance concerns. > > > > > > I think we have to demonstrate that there > > > are legitimate performance concerns before we > > > solve for them. > > > > > > > Agreed. > > > > > Sanity check: we're talking about a > > > hypothetical case where the SIP UA is > > > in the handset, right? We're not talking > > > about the case where you're terminating SIP > > > at the next logical hop up (BTS, MSC) for > > > legacy, right? I'm talking about the former. > > > In the latter, its debatable which proxy > > > should do routing. > > > > > > > I was talking about both. The legacy situtation will be important for > > some time, particularly in the North American case where the 2G and > > 3G spectrum allocations overlap. But I think the core network design > > should be there for smooth transition to the SIP based handset. > > > > jak > > > > _______________________________________________ > > 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 -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 08:38:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04211 for ; Wed, 17 May 2000 08:38:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6236C4436B; Wed, 17 May 2000 08:29:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 906FB44352 for ; Wed, 17 May 2000 08:29:43 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id OAA20755 for ; Wed, 17 May 2000 14:35:39 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id OAA02856 for ; Wed, 17 May 2000 14:34:19 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id OAA24664 for ; Wed, 17 May 2000 14:34:41 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA70DE; Wed, 17 May 2000 14:44:33 +0200 Message-ID: <39228CBB.CE13BE3A@italtel.it> Date: Wed, 17 May 2000 14:12:44 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Giuseppe Ricagni wrote: > > > I was just talking about the PDD (post dial delay) for a call that can > > be processed > > locally, without any kind of message sent to the home network. > > I think the RTT for going to the home network is going to be a drop in > the bucket compared to the typical PDDs in wireless today. The RTT for > going to the home network is going to have to be reasonable to carry > voice anyway, so we are talking a few hundred milliseconds, worst case? > It takes my cell phone 5 seconds for PDD now.... Well, you might want to consider changing mobile operator... :-)) > > > > > Morever, if we start from the assumption (for the above mentioned > > reasons) that all SIP > > signalling goes through at least one proxy, the advantages of having a > > local proxy is > > relevant for example in case of (SIP, hard) handovers (I' m always > > referring to Henning' s approach to SIP mobility). The reduced RTT > > results in a much smaller number of lost packets. > > How is that? Its a dangerous game to make strong assumptions on loss > models like this. > I think we are talking about two different things. I was just sayng that, according to Henning's model, to put it very simple, when you change IP address you shuld send an Invite to your correspondent host containing your new IP address (plus re-registering with your proxy, to allow for signalling to be sent to the new address). If we assume (by hipotesys) that all SIP messages must go through at least 1 proxy, and if we have an active conversation between two Italian mobiles located in Australia, the so called "handoff delay" is one RTT between Australia and Italy, which can be something like 300 msec or (very likely) more. Even with a 300msec figure, you would en up losing some 15 voice samples, which is something definetly undesirable. OTOH, with a local proxy, you wouldn' t lose more than 1 or, at worst, two samples. Giuseppe > > In any case, I think that optimizing an architecture based on > assumptions about loss distributions and latency is somewhat > short-sighted. Lousy network quality is going to kill you on the > compressed voice traffic long before the signaling gets really blown > away. Even from a human factors perspective, most people will tolerate > long PDDs but not high voice packet loss rates. If the signaling loss is > really bothering you, deploy good networks with diffserv giving great > service to port 5060. Eventually these network performance problems will > get solved. But, fundamental architectural decisions don't get changed. > The ability to choose anyone as my applications provider, and not suffer > horrible voice quality (since the audio always goes direct) is such a > huge win for competition and service innovation. Saying no to that to > save 50ms on signaling latency seems such a shame. This was my point > about web. If I had to *rely* on my ISP replicating the content in order > to fetch it, there never would have been a web. It is only because > anyone, anywhere on the Internet could set up shop, and anyone, anywhere > could access it, that we had the huge growth in this service. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 08:51:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04341 for ; Wed, 17 May 2000 08:51:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 627AA44360; Wed, 17 May 2000 08:44:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by lists.bell-labs.com (Postfix) with ESMTP id E4EAE4434A for ; Wed, 17 May 2000 08:44:25 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id IAA21311; Wed, 17 May 2000 08:51:26 -0400 (EDT) Message-ID: <3922962C.E9B5433C@cs.columbia.edu> Date: Wed, 17 May 2000 08:53:00 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Giuseppe Ricagni Cc: Jonathan Rosenberg , Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit There seem to be two cases: 1) The callee is local and the caller is roaming. In that case, there's no reason to have the caller go through its remote (home) proxy for sending SIP requests (except if that home proxy performs, for example, authentication services). 2) The callee is roaming (independent of where the caller is). The SIP call has no choice but to go the home proxy of the callee first, since that's the only reference point for the caller. It has no clue that the callee is standing right next to him/her. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 09:27:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04794 for ; Wed, 17 May 2000 09:27:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BEAC644343; Wed, 17 May 2000 09:19:48 -0400 (EDT) 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 847EB44337 for ; Wed, 17 May 2000 09:19:45 -0400 (EDT) Received: by SPEED01 with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 15:23:06 +0200 Message-ID: <2160ABC55998D311821900508B2C14BB269D4B@SPEED01> From: =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= To: "'James Kempf '" , "'Michael Thomas '" , "'Giuseppe Ricagni '" Cc: "'jdrosen@dynamicsoft.com '" , "'sip@lists.bell-labs.com '" , "'Michael Thomas '" Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Wed, 17 May 2000 15:23:05 +0200 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04794 The home proxy always should be within the signaling path, even though you have roamed into another network. This is very important from a value added service perspective. I have no opinion if is bad or not to force a client to signal through a proxy in the visited network or not. There could be other reasons than billing to do this, for example would the visited network do some logging, or needs to route the messages through a SIP aware firewall. Note that I am not proposing firewalls to be there, but some operators might want them... I think that billing for media (i.e. voice) must be coupled to the transport layer. The reason to have the home proxy within the signaling path is to be able to offer services that is invoked before the call is set up. One example is a speed dial dial service that translates one request URI to something else depending on a users preferences. Is it correct for a UAC to add a route header to indicate to a proxy in the visited network that it should forward the request to the home server? Section 6.37 is a bit confusing since it says "The route request-header field determines the route taken by a request..." I guess it should be changed to "The route request-header field determines the route a request will take..." since it not yet been routed this way when the field is added. I have understood that some groups proposes a solution where the services is downloaded to the visited network. The solution with downloaded services has one severe problem, the fact that the execution environment must be homogenous between the operators. This is very limiting for a operator that want to distinguish himself and attract customers by providing creative services, which is very important on todays competitive market. A successful service might need to retrive information from an information system that the users service provider has access to. This means that althouh the code will be able to execute when it is downloaded to the visited network so will the information that is needed not be accessible. I don't think this would affect the call setup time in any significant way, and users is today used to longer call setup times when the roam into another operators network. /Jörgen -----Original Message----- From: James Kempf To: Michael Thomas; Giuseppe Ricagni Cc: jdrosen@dynamicsoft.com; sip@lists.bell-labs.com; James Kempf; Michael Thomas Sent: 2000-05-16 14:05 Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide >Giuseppe Ricagni writes: > > * possible optimizations (e.g.: signalling for a basic call to an >Australian > > fixed network number from an Italian mobile roaming to Australia could >be > > processed locally, without any "tromboning") > > If during call setup there needs to be a round > trip to the home network, it pretty much negates > any advantage of proxying the call locally. > When you take roaming into account, there is an advantage. Suppose the Italian now in Australia moves. If the home proxy is used, the network has to go back to the home to roam. If a local proxy is used, there is reduced latency. With a local proxy, you pay the round trip cost to the home network just once. In addition, some people have been talking about using SIP for other kinds of in-call signalling. If the mobile has to go all the way back to the home proxy, there is simply too much latency. _______________________________________________ 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 May 17 09:41:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05029 for ; Wed, 17 May 2000 09:41:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99DED4437C; Wed, 17 May 2000 09:34:19 -0400 (EDT) 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 E449444337 for ; Wed, 17 May 2000 09:34:12 -0400 (EDT) Received: from fokus.gmd.de (shaky [193.175.132.94]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA15139; Wed, 17 May 2000 15:39:13 +0200 (MET DST) Message-ID: <39228AB8.E9906C6E@fokus.gmd.de> Date: Wed, 17 May 2000 14:04:08 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow Cc: sip Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Bellow. > Glenn Morrow wrote: > > No, this does *not* work. The body of the SIP message is encrypted with > the public key of the target in the To field. This is therefore not > readable by anyone except the recipient, which means that NAT, > co-located with a proxy or otherwise, can't see it. Normal proxies don't > need to see it, but an ALG does. Thats why SIP doesn't work through NATs > when encrypted. But, hop by hop does work, since the proxy can decrypt > the message. > > I definitely agree if we are talking about a NAT-PT/ALG that is trying to be a SIP firewall/proxy as well. > > Do you agree that a NAT that is not concerned with the port i.e. a simple NAT/firewall for security, denial of service, etc.. would have a problem with this method if indeed there was a protected SIP proxy behind the NAT/firewall? > > Sorry again - there are so many forms of NAT/proxy/firewall and different uses for each. > There are two problems: 1) SIP does not work with firewalls at all unless they are SIP-aware (probably the problem you are asking about, right?) Solution is straightforward: teach firewalls to speak SIP (reworded more generally: include ALGs); SIP-awareness can be either embedded in the firewalls or SIP-proxies can be reused for this purpose if an interface between them and firewalls is provided. IMHO, the latter alternative is preferable. 2) The second separate issue is that even if the firewalls are SIP-aware it doesn't help if the SIP messages are e2e encrypted. This is not a technical problem. This is network security configuration problem. Either your network administrator wants to eliminate traffic considered dangerous (e.g., SIP INVITEs with ILOVEYOU, unsolicited media) centrally with firewalls and thus has to inspect signaling (yes, this implies the SIP proxy administrator will know you received video from Mary at port X), or he has no firewalls and lets you do what you want to (including privacy by encryption and receiving ILOVEYOU). The only technical issue here is (we seem to have consensus on it) a) usage of a SIP reply which says "my firewall cannot decrypt your message" b) go for hop-by-hop encryption (the administrator still knows about you and Mary but eavedroppers do not) To answer your question: I do not see the problem with SIP-aware NATs/FWs and HbH encryption other than your administrator seeing your signaling. If you want to have e2e encryption of your session with Mary use your ISP w/o FWs instead of your corporate network with them. Jiri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 10:08:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05331 for ; Wed, 17 May 2000 10:08:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CDB0644339; Wed, 17 May 2000 10:01:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from witbier.cisco.com (witbier.cisco.com [171.71.152.57]) by lists.bell-labs.com (Postfix) with ESMTP id BB83244337 for ; Wed, 17 May 2000 10:01:20 -0400 (EDT) Received: from mramalho-nt1 (ssh.cisco.com [171.69.10.34]) by witbier.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id HAA09178; Wed, 17 May 2000 07:08:24 -0700 (PDT) Message-Id: <4.1.20000517090137.00a58290@localhost> X-Sender: mramalho@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 May 2000 10:10:05 -0400 To: Jonathan Rosenberg , Giuseppe Ricagni From: "Michael A. Ramalho" Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com In-Reply-To: <392221A5.CB601993@dynamicsoft.com> References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 12:35 AM 5/17/00 -0400, Jonathan Rosenberg wrote: > > >Giuseppe Ricagni wrote: >> >> Jonathan, Michael: >> > > >> > > Giuseppe Ricagni writes: >> > > > * possible optimizations (e.g.: signalling for a basic call to >an Australian >> > > > fixed network number from an Italian mobile roaming to >Australia could be >> > > > processed locally, without any "tromboning") >> > > >> > > If during call setup there needs to be a round >> > > trip to the home network, it pretty much negates >> > > any advantage of proxying the call locally. >> > >> > Please note that this service (optimized dial plans based on roaming) is >> > still possible even if I go directly to the home network. All I need to >> > do is indicate to my home proxy where I am, so it knows what dial plan >> > to apply. In fact, dial plan administration is, in general, a service >> > that can be outsourced to any ASP (of course, only local ASPs may wish >> > to provide it, but the point is anyone can). >> > >> >> I was just talking about the PDD (post dial delay) for a call that can >> be processed >> locally, without any kind of message sent to the home network. > >I think the RTT for going to the home network is going to be a drop in >the bucket compared to the typical PDDs in wireless today. The RTT for >going to the home network is going to have to be reasonable to carry >voice anyway, so we are talking a few hundred milliseconds, worst case? >It takes my cell phone 5 seconds for PDD now.... FWIW - I would love only 5 seconds! My home office phone (Bell Atlantic) is often forwarded to my AT&T Wireless phone. However, I'm usually in a Comcast serving area (i.e., roaming). When I am at home when someone calls my forwarded home office phone ... it pings (to let me know a call has been forwarded) ... then I wait .... and wait some more ..... usually 6 to 8 seconds MINIMUM ... before my cell rings. And that is over and above the usual PDD to Bell Atlantic. Why do I put up with it? Two reasons ... 1) no other choice and 2) most time the Caller-ID is provided so I can call back the party that has just given up on me because of the long PDD. Just think of how many SS7 messages and voice trunk seizures were required for the present PSTN in this case ..... every hop "set up" requires signaling ... in this case between three service provider (trust) boundaries. How can the RTT for going back to the home network (for the simple, no special features case, only once) be worse than what I have now? And I consider what I have now a useful service ... considering the alternative. Every replacement technology challenges some of the "requirements" upon which the present generation of technology is built upon. Optimizing PDD for the PSTN-to-PSTN phone call was one of these requirements. And while I still agree that minimizing PDD with some reasonableness of the tradeoffs involved is still a laudable goal ... one should compare the PDD tradeoffs of todays mobile/cellular world to indeed verify that what we propose is - in many cases - ALREADY BETTER than some usual mobility cases (like my experience above). As for the loss arguments .... I also agree with Jonathan. Moreover, we have taken steps in IETF/sigtran to create transports that do not have the head of line blocking and do have "fast retransmit" capability that our more time sensitive signaling messages require (i.e., SCTP). > > >> >> Morever, if we start from the assumption (for the above mentioned >> reasons) that all SIP >> signalling goes through at least one proxy, the advantages of having a >> local proxy is >> relevant for example in case of (SIP, hard) handovers (I' m always >> referring to Henning' s approach to SIP mobility). The reduced RTT >> results in a much smaller number of lost packets. > >How is that? Its a dangerous game to make strong assumptions on loss >models like this. > >In any case, I think that optimizing an architecture based on >assumptions about loss distributions and latency is somewhat >short-sighted. Lousy network quality is going to kill you on the >compressed voice traffic long before the signaling gets really blown >away. Even from a human factors perspective, most people will tolerate >long PDDs but not high voice packet loss rates. If the signaling loss is >really bothering you, deploy good networks with diffserv giving great >service to port 5060. Eventually these network performance problems will >get solved. But, fundamental architectural decisions don't get changed. >The ability to choose anyone as my applications provider, and not suffer >horrible voice quality (since the audio always goes direct) is such a >huge win for competition and service innovation. Saying no to that to >save 50ms on signaling latency seems such a shame. This was my point >about web. If I had to *rely* on my ISP replicating the content in order >to fetch it, there never would have been a web. It is only because >anyone, anywhere on the Internet could set up shop, and anyone, anywhere >could access it, that we had the huge growth in this service. > >-Jonathan R. > >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (732) 741-4778 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > Michael A. Ramalho, Ph.D. Cisco Systems 1802 Rue de la Port Wall Township, NJ 07719-3784 Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.732.449.5762 Cell: +1.732.809.0188 Pager: +1.800.365.4578 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 10:14:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05375 for ; Wed, 17 May 2000 10:14:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81EAE4438B; Wed, 17 May 2000 10:06:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 271044437A for ; Wed, 17 May 2000 10:06:40 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id QAA29488 for ; Wed, 17 May 2000 16:12:40 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id QAA11881 for ; Wed, 17 May 2000 16:11:22 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id QAA12152 for ; Wed, 17 May 2000 16:11:39 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA441; Wed, 17 May 2000 16:21:34 +0200 Message-ID: <3922A84E.3D4DE66A@italtel.it> Date: Wed, 17 May 2000 16:10:23 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Jonathan Rosenberg , Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <3922962C.E9B5433C@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning, Henning Schulzrinne wrote: > There seem to be two cases: > > 1) The callee is local and the caller is roaming. In that case, there's > no reason to have the caller go through its remote (home) proxy for > sending SIP requests (except if that home proxy performs, for example, > authentication services). > right ! This also applies to roaming mobile-to-fixed, local endpoint. Authentication is the real open issue at the moment, but what about having a full authentication involving the home domain at registration time (when I switch on the mobile), and a local authentication with the local proxy when the endpoint sends the Invite ? Would this be feasible ? > > 2) The callee is roaming (independent of where the caller is). The SIP > call has no choice but to go the home proxy of the callee first, since > that's the only reference point for the caller. It has no clue that the > callee is standing right next to him/her. As long as I set up a brand new call, you are absolutely right. In my handover example, anyway, I was sending a new Invite with the same call identifier of an existing call just to update the IP address where my correspondent should send voice traffic, and I was trying to reduce the handoff delay to a minimum. The costraint I put was that all SIP messages were going through at least 1 proxy. Now, if both terminals are roaming, and they are in the same domain (typical case of two friends on vacation), since there already is an established call between the two, the local proxy sholud be able to route the Invite message towards the correspondent host without involving the home network. Correct ? Thank you Giuseppe -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 11:29:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06155 for ; Wed, 17 May 2000 11:29:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 121E644346; Wed, 17 May 2000 11:22:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 6BB0B44337 for ; Wed, 17 May 2000 11:22:17 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id RAA06379 for ; Wed, 17 May 2000 17:28:10 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id RAA18961 for ; Wed, 17 May 2000 17:26:51 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id RAA25584 for ; Wed, 17 May 2000 17:27:10 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA997; Wed, 17 May 2000 17:37:03 +0200 Message-ID: <3922BBD5.A776F322@italtel.it> Date: Wed, 17 May 2000 17:33:41 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?J=F6rgen=20Bj=F6rkner?= , James Kempf , Michael Thomas , Giuseppe Ricagni , Jonathan Rosenberg Subject: SIP architecture for Roaming mobiles (was RE: [SIP] Minutes of SIP Security task force in Adelaide) Content-Type: multipart/alternative; boundary="------------66FDDE02B0E4D01E2733D4A2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------66FDDE02B0E4D01E2733D4A2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear All, I thought about generating a new thread as our discussion had completely diverged from the purpose of the previous thread Jörgen Björkner wrote: > > The home proxy always should be within the signaling path, even though > you > have roamed into another network. This is very important from a value > added > service perspective. there are four kind of value added services: * a) those who require user profile information * b) those who don' t require user profile information, but to some extent they are not supported by the visited domain * c) those who don' t require user profile information and they are implemented by the visited domain. * d) null services: in other words, basic calls tha do not request any kind of value added service Case a) and b) require some kind of interaction with the home network. C) and d) don' t. > [...] > The reason to have the home proxy within the signaling path is to be > able to > offer services that is invoked before the call is set up. One example > is a > speed dial dial service that translates one request URI to something > else > depending on a users preferences. This is a type a) service. Yes, you need to execute it in the home network, unless you download the user profile at registration time AND the visited network has implemented that specific service. With respect to the method used to classify service request within the four cathegories, a possibility is that the home domain, at registration time, sends information to the visited domain on the requirements to meet to locally execute a given set of services for that specific user. If the visited domain supports such requirements ==> those services can be executed locally. This mechanism can even be extended to the full download of the user profile. > [...] > I have understood that some groups proposes a solution where the > services is > downloaded to the visited network. The solution with downloaded > services has > one severe problem, the fact that the execution environment must be > homogenous between the operators. The real problem I see here is a secuity one: PNOs will never allow 3rd pty code to run on thei mission-critical machines. > This is very limiting for a operator that > want to distinguish himself and attract customers by providing > creative > services, which is very important on todays competitive market. A > successful > service might need to retrive information from an information system > that > the users service provider has access to. This means that althouh the > code > will be able to execute when it is downloaded to the visited network > so will > the information that is needed not be accessible. > I don't think this would affect the call setup time in any significant > way, > and users is today used to longer call setup times when the roam into > another operators network. Please see my othe messages Giuseppe > > /Jörgen > > -----Original Message----- > From: James Kempf > To: Michael Thomas; Giuseppe Ricagni > Cc: jdrosen@dynamicsoft.com; sip@lists.bell-labs.com; James Kempf; > Michael > Thomas > Sent: 2000-05-16 14:05 > Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide > > >Giuseppe Ricagni writes: > > > * possible optimizations (e.g.: signalling for a basic call to > an > >Australian > > > fixed network number from an Italian mobile roaming to > Australia could > >be > > > processed locally, without any "tromboning") > > > > If during call setup there needs to be a round > > trip to the home network, it pretty much negates > > any advantage of proxying the call locally. > > > > When you take roaming into account, there is an advantage. Suppose the > > Italian now in Australia moves. If the home proxy is used, the network > > has to go back to the home to roam. If a local proxy is used, there is > > reduced latency. With a local proxy, you pay the round trip cost > to the home network just once. > > In addition, some people have been talking about using SIP for other > kinds of in-call signalling. If the mobile has to go all the way > back to the home proxy, there is simply too much latency. > > _______________________________________________ > 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 -- -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- --------------66FDDE02B0E4D01E2733D4A2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear All,

I thought about generating a new thread as our discussion had completely diverged from the purpose of the previous thread

Jörgen Björkner wrote:

 
The home proxy always should be within the signaling path, even though you
have roamed into another network. This is very important from a value added
service perspective.
there are four kind of value added services:
  • a) those who require user profile information
  • b) those who don' t  require user profile information, but to some extent they are not supported by the visited domain
  • c) those who don' t  require user profile information and they are implemented by the visited domain.
  • d) null services: in other words, basic calls tha do not request any kind of value added service
Case a) and b) require some kind of interaction with the home network.

C) and d) don' t.

 
[...]
The reason to have the home proxy within the signaling path is to be able to
offer services that is invoked before the call is set up. One example is a
speed dial dial service that translates one request URI to something else
depending on a users preferences.
This is a type a) service. Yes, you need to execute it in the home network, unless you download the user profile at registration time AND the visited network has implemented that specific service.

With respect to the method used to classify service request within the four cathegories, a possibility is that  the home domain, at registration time, sends information to the visited domain on the requirements to meet  to locally execute a given set of services for that specific user. If the visited domain supports such requirements ==> those services can be executed locally.

This mechanism can even  be extended to the full download of the user profile.

 
[...]
I have understood that some groups proposes a solution where the services is
downloaded to the visited network. The solution with downloaded services has
one severe problem, the fact that the execution environment must be
homogenous between the operators.
The real problem I see here is a secuity one: PNOs will never allow 3rd pty code to run on thei mission-critical machines.
This is very limiting for a operator that
want to distinguish himself and attract customers by providing creative
services, which is very important on todays competitive market. A successful
service might need to retrive information from an information system that
the users service provider has access to. This means that althouh the code
will be able to execute when it is downloaded to the visited network so will
the information that is needed not be accessible.
I don't think this would affect the call setup time in any significant way,
and users is today used to longer call setup times when the roam into
another operators network.
Please see my othe messages

Giuseppe

 
/Jörgen

-----Original Message-----
From: James Kempf
To: Michael Thomas; Giuseppe Ricagni
Cc: jdrosen@dynamicsoft.com; sip@lists.bell-labs.com; James Kempf; Michael
Thomas
Sent: 2000-05-16 14:05
Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide

>Giuseppe Ricagni writes:
> >    * possible optimizations (e.g.: signalling for a basic call to an
>Australian
> >      fixed network number from an Italian mobile roaming to
Australia could
>be
> >      processed locally, without any "tromboning")
>
>   If during call setup there needs to be a round
>   trip to the home network, it pretty much negates
>   any advantage of proxying the call locally.
>

When you take roaming into account, there is an advantage. Suppose the
Italian now in Australia moves. If the home proxy is used, the network
has to go back to the home to roam. If a local proxy is used, there is
reduced latency. With a local proxy, you pay the round trip cost
to the home network just once.

In addition, some people have been talking about using SIP for other
kinds of in-call signalling. If the mobile has to go all the way
back to the home proxy, there is simply too much latency.

_______________________________________________
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

--

--
----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------
  --------------66FDDE02B0E4D01E2733D4A2-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 11:56:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06709 for ; Wed, 17 May 2000 11:56:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0705A4435D; Wed, 17 May 2000 11:49:09 -0400 (EDT) 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 62CF344358 for ; Wed, 17 May 2000 11:49:06 -0400 (EDT) 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 LAA17629; Wed, 17 May 2000 11:56:21 -0400 (EDT) Message-ID: <3922C124.4C3803E9@cs.columbia.edu> Date: Wed, 17 May 2000 11:56:20 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Michael A. Ramalho" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <4.1.20000517090137.00a58290@localhost> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Just as a data point: Tony Eyers and I have looked at signaling performance under redirect and proxy assumptions, for both ("optimized") TCP and UDP. See the paper in the IPtel 2000 workshop at http://www.fokus.gmd.de/events/iptel2000/pg.php3 This is based on recent real Internet measurements, assuming that SIP will not use either reserved flows or BBE diff-serv classes. If one were to use standard TCP with its long initial retransmit timer, things get really bad (we didn't look at this since it's too bad to be interesting...), but even with cross-country redirection, call setup delays are rather modest. Note that we looked at percentiles, not averages. "Michael A. Ramalho" wrote: > > FWIW - I would love only 5 seconds! > > My home office phone (Bell Atlantic) is often forwarded to my AT&T Wireless > phone. However, I'm usually in a Comcast serving area (i.e., roaming). > > When I am at home when someone calls my forwarded home office > phone ... it pings (to let me know a call has been forwarded) ... then I > wait .... and wait some more ..... usually 6 to 8 seconds MINIMUM ... before > my cell rings. And that is over and above the usual PDD to Bell Atlantic. > > Why do I put up with it? Two reasons ... 1) no other choice and 2) most > time the Caller-ID is provided so I can call back the party that has just > given up on me because of the long PDD. > > Just think of how many SS7 messages and voice trunk seizures were > required for the present PSTN in this case ..... every hop "set up" requires > signaling ... in this case between three service provider (trust) boundaries. > > How can the RTT for going back to the home network (for the simple, no > special features case, only once) be worse than what I have now? And I > consider what I have now a useful service ... considering the alternative. > > Every replacement technology challenges some of the "requirements" > upon which the present generation of technology is built upon. Optimizing > PDD for the PSTN-to-PSTN phone call was one of these requirements. > And while I still agree that minimizing PDD with some reasonableness of > the tradeoffs involved is still a laudable goal ... one should compare the > PDD tradeoffs of todays mobile/cellular world to indeed verify that what > we propose is - in many cases - ALREADY BETTER than some usual > mobility cases (like my experience above). > > As for the loss arguments .... I also agree with Jonathan. Moreover, we > have taken steps in IETF/sigtran to create transports that do not have the > head of line blocking and do have "fast retransmit" capability that our > more time sensitive signaling messages require (i.e., SCTP). > -- 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 May 17 12:10:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07548 for ; Wed, 17 May 2000 12:10:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D26244348; Wed, 17 May 2000 12:03:21 -0400 (EDT) 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 A93E144337 for ; Wed, 17 May 2000 12:03:18 -0400 (EDT) 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 MAA18552; Wed, 17 May 2000 12:10:32 -0400 (EDT) Message-ID: <3922C478.B20B1D50@cs.columbia.edu> Date: Wed, 17 May 2000 12:10:32 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Giuseppe Ricagni ]" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <3922962C.E9B5433C@cs.columbia.edu> <3922A84E.3D4DE66A@italtel.it> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Giuseppe Ricagni wrote: > > Henning, > > Henning Schulzrinne wrote: > > > There seem to be two cases: > > > > 1) The callee is local and the caller is roaming. In that case, there's > > no reason to have the caller go through its remote (home) proxy for > > sending SIP requests (except if that home proxy performs, for example, > > authentication services). > > > > right ! > This also applies to roaming mobile-to-fixed, local endpoint. > > Authentication is the real open issue at the moment, but what about having > a full authentication involving the home domain at registration time (when > I switch on the mobile), and a local authentication with the local proxy > when the endpoint sends the Invite ? Would this be feasible ? I should have been more precise: we need to distinguish roaming between domains (from, say, columbia.edu to stanford.edu) and roaming between proxies that share information/data (say, detroit.att.com and nyc.att.com). In the latter case, presumably the Detroit server has access to my NY "home" entry and can perform all normal outbound proxy functions, including any outbound scripts, address books or other personalized logic. The tricky part is how the UA decides what to do. We have three local-proxy mechanisms: - DHCP - multicast - local configuration (hard-wired) The first two would presumably point to stanford.edu or detroit.att.com as I roam away from Columbia, while the third is likely to be always nyc.att.com. With the DHCP option, the UA could guess as to whether to use the home proxy or not, based on domain name. It would have to know, somehow, whether the proxy is sharing information with home or not. > In my handover example, anyway, I was sending a new Invite with the same > call identifier of an existing call just to update the IP address where my > correspondent should send voice traffic, and I was trying to reduce the > handoff delay to a minimum. The costraint I put was that all SIP messages > were going through at least 1 proxy. See our SIP mobility paper and other more recent work that addresses this, at a high level. We still need to work out the details as to how this work, as it requires that the "away" proxy proxying the registration modifies the Contact to point to it rather than the mobile, for example. > > Now, if both terminals are roaming, and they are in the same domain > (typical case of two friends on vacation), since there already is an > established call between the two, the local proxy sholud be able to route > the Invite message towards the correspondent host without involving the > home network. > > Correct ? Again, this depends on naming and whether a local outbound proxy allows "foreign" registrations. If I visit Stanford and the Stanford proxy allows me to register with my cs.columbia.edu address AND somehow short-circuits INVITEs from a Stanford caller to me (using my cs.columbia.edu address), this avoids the trip home, but has obviously bad consequences if I'm relying on my cs.columbia.edu proxy to do call filtering for me. Thus, I may not particularly appreciate that *unless* I can get the Stanford proxy to inherit my call logic. Currently, I can only do this by uploading the CPL script, say, which means my mobile has to carry it around. One could presumably allow a level of indirection where I register at Stanford with my a pointer to my canonical master CPL script. I doubt whether this complexity is worth the minor saving in call setup delay. Thus, just about anything can be done, depending on naming, but each choice has consequences on available call features. -- 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 May 17 12:18:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07824 for ; Wed, 17 May 2000 12:18:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 22F894437A; Wed, 17 May 2000 12:11:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 6B8444434A for ; Wed, 17 May 2000 12:11:06 -0400 (EDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4HGIMq20198 for ; Wed, 17 May 2000 18:18:22 +0200 (MET DST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FUP00K01PAMPN@mbb1.ericsson.se> for sip@lists.bell-labs.com; Wed, 17 May 2000 18:18:22 +0200 (MET DST) Received: from era.ericsson.se (kipf155.eraj.ericsson.se [147.214.69.155]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FUP00K61PALCN@mbb1.ericsson.se>; Wed, 17 May 2000 18:18:22 +0200 (MET DST) Date: Wed, 17 May 2000 16:58:07 +0200 From: Stephen Terrill Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide To: Giuseppe Ricagni Cc: James.Kempf@Eng.Sun.COM, Michael Thomas , sip@lists.bell-labs.com, Jonathan Rosenberg Message-id: <3922B37F.B6D7CF97@era.ericsson.se> Organization: L.M. Ericsson MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win98; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <200005162222.PAA05644@nasnfs.eng.sun.com> <39223BAF.DBA2A87D@ericsson.com> <392292D7.DD06C377@italtel.it> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8BIT Hi Giuseppe, One correction, in the deployed SS7 networks today, there is only a single 64kbs pipe available to the call (the signalling for one call is not split over several signalling links). As such, the faster transport does reduce the latency - and I don´t believe that anyone is considering running the signalling on an improperly dimensioned/configured network. Regards, ..//steve Giuseppe Ricagni wrote: > Stephen, > > Stephen Terrill wrote: > > > Hi James, > > > > I think that the emphansis on saving the trombing of the user signalling is much overweighted. Firstly, the "singlling" transport in these networks is not limited to the 64kbs singnalling channels used in the PSTN today. > > Higher bandwidth doesn' t necessarily mean lower latency..... Moreover > you don' t normally have *just one* 64Kb/s link. In this > specific case, the tight delay requirements on SS7 networks, might well > result in lower RTTs for signalling messages. > > > Secondly, even today, it is not uncommon for two operators in the same country (ie a european country) to interconnect to each other by going through the US due to commercial reasons (ie a call from one phone to another phone just 30 meeters away can cross the atlantic twice). What I am saying as that this happens today, and that is both user signalling and payload, and customer usually aren´t aware of it. > > > > not saying that signalling should *always* be processed locally: as you > know this is just impossible, especially when user profile data is > required to process the call. > > What we are claiming here is that local procesing should be employed as > an optimization, in all those cases where it is actually possible, > without any (pre-call) data exchange with the home domain. > > > As such, I do tend to agree with Jonathan and Mike that the advantages of taking the call/session signalling to the "home" proxy outweigh this small and dissappearing disadvantage. > > I do tend to disagree... Why not applying an optimization (only in those > cases where it can be applied, obviously) if it's easy, it has basically > no disadvantages, and it can be even much more helpful in other contexts > (seen my other posting ?) > > Cheers > Giuseppe > P.S. > BTW: you will remember that “Optimised call routing” is a requirement > for 3G networks (it does also refer to signalling).... > > > > > > > Regards, > > > > ..//steve > > > > James Kempf wrote: > > > > > >James Kempf writes: > > > > > I don't think the analogy between SIP and HTTP is valid. I see it more > > > > > as being between SIP and routing. Suppose I would have to go all the > > > > > way back to my home network to get my packets routed. > > > > > > > > This is a pretty dubious analogy. We're talking > > > > about proxy-routed signaling traffic and that > > > > alone. You're making it sound like the media > > > > would do dog-leg routing through the home > > > > network which is absurd. > > > > > > > > > > No, that's not what I meant. Thhe point I was trying to make is that > > > I don't think people will be very happy if it takes them > > > substantially longer to make a telephone connection remotely than it > > > does at home. It can take somewhat longer (as it does today in the > > > circuit switched world) but not *substantially* longer. I don't have > > > the numbers for intercontinental routing delays in my head but I can > > > believe they must be more than routing delays to a local ISP. Whether > > > those delays will, in fact, be substantial enough to merit having > > > local proxies is a matter that can be solved by engineering analysis > > > (and not political posturing, as this thread seems to have degenerated into). > > > > > > > > Even if you are willing to grant the analogy, HTTP requests nowadays often > > > > > don't get routed to the server that somebody set up as their web site. > > > > > If your ISP is concerned about service, they may have set up an Inktomi > > > > > cache, and if the publisher is concerned, they may have contracted with > > > > > Akami to do the same. So the world is not so simple as "let's make it > > > > > free and easy for anybody to set up service" on the Web anymore. > > > > > > > > You're assuming that every thing is going to > > > > be a gigantic commercial service. I disagree. > > > > It's still perfectly possible for me to run a > > > > web server at home, and in fact I do. We > > > > haven't engineered walls around that > > > > possibility. Requiring that I use a foreign > > > > proxy does, or at least thinks it does. > > > > > > > > > > Your web server at home is leveraging off the fact that a company, > > > probably AT&T back when they had a monopoly, strung a wire to your > > > house and installed switching equipment at the local office. They made the infrastructue > > > investment years ago that now allows you and your ISP to offer service > > > really cheaply. You may be limited as to the bandwidth you get, due > > > to the fact that your current local telephone provider is not willing > > > to make the infrastructure investment to upgrade to fiber. > > > > > > The UK government just auctioned off UMTS licenses for something like $25B > > > (as in 1 with 9 zeros behind it). Anyone who is not able to come up > > > with that kind of cash will have a hard time offering wireless > > > telephony service. It will take years to amortize that kind of investment. > > > Of course, there is always the unlicensed spectrum and I'm sure there > > > will be players like Metricom who figure out creative ways to utilize it. > > > > > > > Also: you're talking about transparent caching, > > > > not proxying in the web case. I've not heard > > > > of any ISP that *require* that I go through > > > > their HTTP proxies. > > > > > > > > > You can > > > > > set up your service, but unless you have a concerned ISP or the money > > > > > to pay Akami, the latency in using your service may cause people to > > > > > go elsewhere. > > > > > > > > This analogy is fatally flawed. Cache's are > > > > great for the mountains of .gif's. There aren't > > > > similar considerations for SIP. Also: even > > > > if you're talking about co-lo servers > > > > distributed geographically, the site owner > > > > still "owns" the site. What you're talking > > > > about here is something run by their > > > > *competition* on your subscriber's behalf. > > > > > > > > Yuck. > > > > > > > > > > Cellular companies already have romaing agreements. There's nothing new about > > > it. > > > > > > With regard to caches v.s. proxies, the only point I was trying to make was > > > that customers want fast service. Whether that service is web page access > > > or connecting for a telephone call. It therefore makes sense to engineer > > > such that the service provider can provide that service, whether it requires > > > transparent caches or local proxies. > > > > > > > > I know this isn't going to be a popular viewpoint, but I think we need > > > > > to be realistic about the design. SIP already contains support for > > > > > telling an incoming caller that a client has moved, I can't see the > > > > > harm in using a remote proxy, given the performance concerns. > > > > > > > > I think we have to demonstrate that there > > > > are legitimate performance concerns before we > > > > solve for them. > > > > > > > > > > Agreed. > > > > > > > Sanity check: we're talking about a > > > > hypothetical case where the SIP UA is > > > > in the handset, right? We're not talking > > > > about the case where you're terminating SIP > > > > at the next logical hop up (BTS, MSC) for > > > > legacy, right? I'm talking about the former. > > > > In the latter, its debatable which proxy > > > > should do routing. > > > > > > > > > > I was talking about both. The legacy situtation will be important for > > > some time, particularly in the North American case where the 2G and > > > 3G spectrum allocations overlap. But I think the core network design > > > should be there for smooth transition to the SIP based handset. > > > > > > jak > > > > > > _______________________________________________ > > > 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 > > -- > ---------------------------------------------------------- > Giuseppe RICAGNI > System Architecture and Product Planning > Broadband Networks > Italtel > via Reiss Romoli - C10 > 20019 Castelletto di Settimo Milanese (MILANO) > ITALY > > mailto:giuseppe.ricagni@italtel.it > ---------------------------------------------------------- > > _______________________________________________ > 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 May 17 12:38:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08305 for ; Wed, 17 May 2000 12:38:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EBCBE4434E; Wed, 17 May 2000 12:30:46 -0400 (EDT) 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 6625F44337 for ; Wed, 17 May 2000 12:30:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 17 12:36:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A892144344; Wed, 17 May 2000 12:23:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 749AF44341 for ; Wed, 17 May 2000 12:23:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0480852C4; Wed, 17 May 2000 12:23:22 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2E0EF52AB for ; Wed, 17 May 2000 12:23:18 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 17 12:22:09 EDT 2000 Received: from ort-mail.outreachtech.com ([208.246.106.18]) by dusty; Wed May 17 12:22:09 EDT 2000 Received: by ORT-MAIL with Internet Mail Service (5.5.2448.0) id ; Wed, 17 May 2000 12:22:03 -0400 Message-ID: <410B13D70EB2D211827E00E0291E9FF7B2BCF4@ORT-MAIL> From: "Vakil, Mohammad" To: sip@lists.research.bell-labs.com Cc: "'Mohammad.Vakil@outreachtech.com'" Date: Wed, 17 May 2000 12:22:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Multimedia Conferencing using SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I read in RFC2543bis, "SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conference control protocols." This is a little confusing because in Abstract of RFC2543bis I read that these sessions(which are created, modified, and terminated using SIP), could also be Internet multimedia conferences..... I skimmed through the document "Distributed Multipoint Conferences using SIP"(draft-mark-sip-dmcs-00). I've a situation where a central server does all the conferencing and I'd like SIP UACs to be able to estabilish a multimedia conference session on that server. e.g. for a conference call, they can specify hostname or IP address of the Conferencing Sever in the SDP and establish the session. Do we have an extension or something, which explains Conferencing on a central server? Any pointers, explanations, or directions would very appreciated. Thanks, Mohammad Vakil _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 13:22:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09053 for ; Wed, 17 May 2000 13:22:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B05784434A; Wed, 17 May 2000 13:15:19 -0400 (EDT) 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 D77F244337 for ; Wed, 17 May 2000 13:15:16 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA29278; Wed, 17 May 2000 10:22:40 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA25890; Wed, 17 May 2000 10:22:33 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14626.54617.648412.299580@thomasm-u1.cisco.com> Date: Wed, 17 May 2000 10:22:33 -0700 (PDT) To: "Dean Willis" Cc: "Jonathan Rosenberg" , "IETF SIP" Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <027401bfbfc5$65c90a80$56fa403f@directlink.net> References: <3921B8D1.46BD94B6@dynamicsoft.com> <027401bfbfc5$65c90a80$56fa403f@directlink.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dean Willis writes: > Actually, I think there might be an exception. Let's say we have a large network that mixes several DiffServe classes -- for simplicity, let's say "best effort" and "priority" clases. Assume that there is normally a relatively high ratio of best-effort to priority traffic in the network. > > One might a heuristic for traffic engineering that works like this: > > Assume a network monitoring system that can > provide both a rough estimate of the ration of > best-effort to priority traffic on the backbone > and on specific links. Feed this data into access > proxies. Doesn't this violate the law of "You are not alone"? Besides, even if it were just EF RTP traffic controlled by SIP proxies, how would they synchronize amongst themselves? Even with the implicit linkage model of signaling and admission authorization of DQoS, it's still the edge routers making the admission control decision from a "can we support the bandwidth" standpoint into the diffserv cloud. 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 May 17 13:35:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09176 for ; Wed, 17 May 2000 13:35:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 983534436F; Wed, 17 May 2000 13:28:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 1BAD44436A for ; Wed, 17 May 2000 13:28:17 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id TAA12880 for ; Wed, 17 May 2000 19:34:18 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id TAA25919 for ; Wed, 17 May 2000 19:33:00 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id TAA11476 for ; Wed, 17 May 2000 19:33:20 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAAF67; Wed, 17 May 2000 19:43:15 +0200 Message-ID: <3922D7EA.DA7897AA@italtel.it> Date: Wed, 17 May 2000 19:33:31 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Terrill Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005162222.PAA05644@nasnfs.eng.sun.com> <39223BAF.DBA2A87D@ericsson.com> <392292D7.DD06C377@italtel.it> <3922B37F.B6D7CF97@era.ericsson.se> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi Stephen, Stephen Terrill wrote: > Hi Giuseppe, > > One correction, in the deployed SS7 networks today, there is only a single 64kbs pipe available to the call (the signalling for one call is not split over several signalling links). As such, the faster transport does reduce the latency - and I don´t believe that anyone is considering running the signalling on an improperly dimensioned/configured network. well, I just thought that by claiming that current SS7 signalling is conveyed on 64 Kbit/s links you were suggesting some kind of conjestion *in the nodes* (STPs). The average ISUP message length, just to make an example, does not normally exceed 40bytes. A 64 Kbit/s link sends a 40 bytes message in 5 milliseconds: I really don' t think this is the bottleneck..... Should you take it to 100 Mbit/s you wouln't gain definetly more than 5 msec !!!! OTOH, the time spent in routers may differ from that spent in STPs, retransmission mechanisms may differ, and so on. Giuseppe > > Regards, > > ..//steve > > Giuseppe Ricagni wrote: > > > Stephen, > > > > Stephen Terrill wrote: > > > > > Hi James, > > > > > > I think that the emphansis on saving the trombing of the user signalling is much overweighted. Firstly, the "singlling" transport in these networks is not limited to the 64kbs singnalling channels used in the PSTN today. > > > > Higher bandwidth doesn' t necessarily mean lower latency..... Moreover > > you don' t normally have *just one* 64Kb/s link. In this > > specific case, the tight delay requirements on SS7 networks, might well > > result in lower RTTs for signalling messages. > > > > > Secondly, even today, it is not uncommon for two operators in the same country (ie a european country) to interconnect to each other by going through the US due to commercial reasons (ie a call from one phone to another phone just 30 meeters away can cross the atlantic twice). What I am saying as that this happens today, and that is both user signalling and payload, and customer usually aren´t aware of it. > > > > > > > not saying that signalling should *always* be processed locally: as you > > know this is just impossible, especially when user profile data is > > required to process the call. > > > > What we are claiming here is that local procesing should be employed as > > an optimization, in all those cases where it is actually possible, > > without any (pre-call) data exchange with the home domain. > > > > > As such, I do tend to agree with Jonathan and Mike that the advantages of taking the call/session signalling to the "home" proxy outweigh this small and dissappearing disadvantage. > > > > I do tend to disagree... Why not applying an optimization (only in those > > cases where it can be applied, obviously) if it's easy, it has basically > > no disadvantages, and it can be even much more helpful in other contexts > > (seen my other posting ?) > > > > Cheers > > Giuseppe > > P.S. > > BTW: you will remember that “Optimised call routing” is a requirement > > for 3G networks (it does also refer to signalling).... > > > > > > > > > > > Regards, > > > > > > ..//steve > > > > > > James Kempf wrote: > > > > > > > >James Kempf writes: > > > > > > I don't think the analogy between SIP and HTTP is valid. I see it more > > > > > > as being between SIP and routing. Suppose I would have to go all the > > > > > > way back to my home network to get my packets routed. > > > > > > > > > > This is a pretty dubious analogy. We're talking > > > > > about proxy-routed signaling traffic and that > > > > > alone. You're making it sound like the media > > > > > would do dog-leg routing through the home > > > > > network which is absurd. > > > > > > > > > > > > > No, that's not what I meant. Thhe point I was trying to make is that > > > > I don't think people will be very happy if it takes them > > > > substantially longer to make a telephone connection remotely than it > > > > does at home. It can take somewhat longer (as it does today in the > > > > circuit switched world) but not *substantially* longer. I don't have > > > > the numbers for intercontinental routing delays in my head but I can > > > > believe they must be more than routing delays to a local ISP. Whether > > > > those delays will, in fact, be substantial enough to merit having > > > > local proxies is a matter that can be solved by engineering analysis > > > > (and not political posturing, as this thread seems to have degenerated into). > > > > > > > > > > Even if you are willing to grant the analogy, HTTP requests nowadays often > > > > > > don't get routed to the server that somebody set up as their web site. > > > > > > If your ISP is concerned about service, they may have set up an Inktomi > > > > > > cache, and if the publisher is concerned, they may have contracted with > > > > > > Akami to do the same. So the world is not so simple as "let's make it > > > > > > free and easy for anybody to set up service" on the Web anymore. > > > > > > > > > > You're assuming that every thing is going to > > > > > be a gigantic commercial service. I disagree. > > > > > It's still perfectly possible for me to run a > > > > > web server at home, and in fact I do. We > > > > > haven't engineered walls around that > > > > > possibility. Requiring that I use a foreign > > > > > proxy does, or at least thinks it does. > > > > > > > > > > > > > Your web server at home is leveraging off the fact that a company, > > > > probably AT&T back when they had a monopoly, strung a wire to your > > > > house and installed switching equipment at the local office. They made the infrastructue > > > > investment years ago that now allows you and your ISP to offer service > > > > really cheaply. You may be limited as to the bandwidth you get, due > > > > to the fact that your current local telephone provider is not willing > > > > to make the infrastructure investment to upgrade to fiber. > > > > > > > > The UK government just auctioned off UMTS licenses for something like $25B > > > > (as in 1 with 9 zeros behind it). Anyone who is not able to come up > > > > with that kind of cash will have a hard time offering wireless > > > > telephony service. It will take years to amortize that kind of investment. > > > > Of course, there is always the unlicensed spectrum and I'm sure there > > > > will be players like Metricom who figure out creative ways to utilize it. > > > > > > > > > Also: you're talking about transparent caching, > > > > > not proxying in the web case. I've not heard > > > > > of any ISP that *require* that I go through > > > > > their HTTP proxies. > > > > > > > > > > > You can > > > > > > set up your service, but unless you have a concerned ISP or the money > > > > > > to pay Akami, the latency in using your service may cause people to > > > > > > go elsewhere. > > > > > > > > > > This analogy is fatally flawed. Cache's are > > > > > great for the mountains of .gif's. There aren't > > > > > similar considerations for SIP. Also: even > > > > > if you're talking about co-lo servers > > > > > distributed geographically, the site owner > > > > > still "owns" the site. What you're talking > > > > > about here is something run by their > > > > > *competition* on your subscriber's behalf. > > > > > > > > > > Yuck. > > > > > > > > > > > > > Cellular companies already have romaing agreements. There's nothing new about > > > > it. > > > > > > > > With regard to caches v.s. proxies, the only point I was trying to make was > > > > that customers want fast service. Whether that service is web page access > > > > or connecting for a telephone call. It therefore makes sense to engineer > > > > such that the service provider can provide that service, whether it requires > > > > transparent caches or local proxies. > > > > > > > > > > I know this isn't going to be a popular viewpoint, but I think we need > > > > > > to be realistic about the design. SIP already contains support for > > > > > > telling an incoming caller that a client has moved, I can't see the > > > > > > harm in using a remote proxy, given the performance concerns. > > > > > > > > > > I think we have to demonstrate that there > > > > > are legitimate performance concerns before we > > > > > solve for them. > > > > > > > > > > > > > Agreed. > > > > > > > > > Sanity check: we're talking about a > > > > > hypothetical case where the SIP UA is > > > > > in the handset, right? We're not talking > > > > > about the case where you're terminating SIP > > > > > at the next logical hop up (BTS, MSC) for > > > > > legacy, right? I'm talking about the former. > > > > > In the latter, its debatable which proxy > > > > > should do routing. > > > > > > > > > > > > > I was talking about both. The legacy situtation will be important for > > > > some time, particularly in the North American case where the 2G and > > > > 3G spectrum allocations overlap. But I think the core network design > > > > should be there for smooth transition to the SIP based handset. > > > > > > > > jak > > > > > > > > _______________________________________________ > > > > 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 > > > > -- > > ---------------------------------------------------------- > > Giuseppe RICAGNI > > System Architecture and Product Planning > > Broadband Networks > > Italtel > > via Reiss Romoli - C10 > > 20019 Castelletto di Settimo Milanese (MILANO) > > ITALY > > > > mailto:giuseppe.ricagni@italtel.it > > ---------------------------------------------------------- > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 13:44:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09229 for ; Wed, 17 May 2000 13:44:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C007E4439D; Wed, 17 May 2000 13:36:48 -0400 (EDT) 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 58C7344363 for ; Wed, 17 May 2000 13:36:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 17 13:42:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9028744344; Wed, 17 May 2000 13:29:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 64BDF44341 for ; Wed, 17 May 2000 13:29:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1EDC352C4; Wed, 17 May 2000 13:29:22 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 32A8E52B6 for ; Wed, 17 May 2000 13:29:19 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 17 13:27:41 EDT 2000 Received: from mail-dns1-nj.dialogic.com ([146.152.228.10]) by dusty; Wed May 17 13:27:40 EDT 2000 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 RAA09067; Wed, 17 May 2000 17:30:02 GMT From: Jeff.Mark@dialogic.com Received: from 100grand (dhcp06.sb.dialogic.com [146.152.131.156]) by mail4.dialogic.com (8.9.3+Sun/8.9.3) with SMTP id NAA00551; Wed, 17 May 2000 13:27:36 -0400 (EDT) To: Cc: Subject: RE: [SIP] Multimedia Conferencing using SIP Date: Wed, 17 May 2000 10:28:00 -0700 Message-ID: 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.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 In-Reply-To: <410B13D70EB2D211827E00E0291E9FF7B2BCF4@ORT-MAIL> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Mohammad, The now expired call control draft (draft-ietf-mmusic-sip-cc-01) describes a SIP bridge which would accomplish the goals you wish describing how a UAC could establish a connection to a centralized conference server without any SIP extensions. See section 4.3 of the draft. Here's a link: http://www.softarmor.com/sipwg/drafts/draft-ietf-mmusic-sip-cc-01.txt It's also important to note the last 2 paragraphs of this section describe a mechanism for one participant in the bridged conference to INVITE another to the conference. This mechanism is still up in the air and is work in progress. -Jeff -- Jeff Mark Intel Dialogic Division Software Engineer 201 Mentor Dr, Suite 100 mailto:Jeff.Mark@dialogic.com Santa Barbara, CA 93111 http://www.dialogic.com (805) 879-3640 (805) 967-1395 fax > -----Original Message----- > From: Vakil, Mohammad [mailto:MVakil@outreachtech.com] > Sent: Wednesday, May 17, 2000 9:22 AM > To: sip@lists.research.bell-labs.com > Cc: 'Mohammad.Vakil@outreachtech.com' > Subject: [SIP] Multimedia Conferencing using SIP > > > > I read in RFC2543bis, "SIP does not offer conference control > services such as floor control or voting and does not > prescribe how a conference is to be managed, but SIP can be > used to introduce conference control protocols." This is a > little confusing because in Abstract of RFC2543bis I read > that these sessions(which are created, modified, and > terminated using SIP), could also be Internet multimedia > conferences..... > > I skimmed through the document "Distributed Multipoint > Conferences using SIP"(draft-mark-sip-dmcs-00). I've a > situation where a central server does all the conferencing > and I'd like SIP UACs to be able to estabilish a multimedia > conference session on that server. e.g. for a conference > call, they can specify hostname or IP address of the > Conferencing Sever in the SDP and establish the session. > Do we have an extension or something, which explains > Conferencing on a central server? Any pointers, explanations, > or directions would very appreciated. > Thanks, > Mohammad Vakil > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 14:10:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09527 for ; Wed, 17 May 2000 14:10:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C13244352; Wed, 17 May 2000 14:02:51 -0400 (EDT) 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 A407344337 for ; Wed, 17 May 2000 14:02:47 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA29207; Wed, 17 May 2000 11:10:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA25909; Wed, 17 May 2000 11:10:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14626.57468.56343.507006@thomasm-u1.cisco.com> Date: Wed, 17 May 2000 11:10:04 -0700 (PDT) To: Cc: "Michael Thomas" , "Jonathan Rosenberg" , , "Giuseppe Ricagni" Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <200005171203.FAA22241@nasnfs.eng.sun.com> References: <200005171203.FAA22241@nasnfs.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf writes: > > I know they do, and my understanding is that > > feature transparency is one thing that suffers > > big time because of their current model. > > Keeping my features back where I get my > > features eliminates that feature synch > > problem at its root. That is impossible in > > the circuit switched world, but almost trivial > > in the SIP world. > > > > If features can be easily forwarded between proxies (with the proper > authentication) then it's even easier to get your features whereever > you want them. That is a monumentally large "if". I know of no system which has solved that satisfactorily on any reasonable scale. Throwing in trust boundaries, and different competing vendors installations is just gravy. I'd claim that this is an intractible problem. Some people might believe that this is solvable, but I remain extremely skeptical. IMO, the best way to deal with intractible problems is to steer well clear of them. 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 May 17 15:34:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10392 for ; Wed, 17 May 2000 15:34:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EC67B44363; Wed, 17 May 2000 15:26:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from opera (ip25.cincinnati13.oh.pub-ip.psi.net [38.31.49.25]) by lists.bell-labs.com (Postfix) with SMTP id 8012E44337; Wed, 17 May 2000 15:26:15 -0400 (EDT) From: Opera9@flash.net Date: Wed, 17 May 2000 15:29:13 -0500 X-Sender: Opera9@flash.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20000517192615.8012E44337@lists.bell-labs.com> Subject: [SIP] Best New Trade Show Display by Opera Portables, Inc. adv Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full of exciting projects and news, Opera is leading the industry with displays that are as much eye-popping as they are eye catching. Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Magazine's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision. If you use displays, you really owe it to yourself to check out our stuff! Go to http://3637331613/ Opera Portables, Inc. All removes honored at http://3637331613/removes.htm _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 17 17:25:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11422 for ; Wed, 17 May 2000 17:25:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C147844373; Wed, 17 May 2000 17:17:28 -0400 (EDT) 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 3298A44337 for ; Wed, 17 May 2000 17:17:21 -0400 (EDT) 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 RAA12582; Wed, 17 May 2000 17:24:29 -0400 (EDT) Message-ID: <39230E0D.84818A9C@cs.columbia.edu> Date: Wed, 17 May 2000 17:24:29 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Sip Mail List Subject: Re: [SIP] Problem with definition of In-Reply-To grammar References: <00051713145204.06188@gethin> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gethin Liddell wrote: > > hi > > I have a problem with the In-Reply-To header, 2543 bis section 6.25 p. 48: > > "The In-Reply-To request header field enumerates the call-IDs that this call references or returns. > This allows automatic call distribution systems to route return calls to the originator of the first call and allows > callees to filter calls, so that only calls that return calls they have originated will be accepted. This field is not a > substitute for request authentication. > > In-Reply-To = In-Reply-To : 1# callid" > > If i can refer you to Anders email titled: > > Re: [SIP] Another grammar query - Call-ID > > then callid has been re-defined as > "Basically, the field should be treated as an opaque, > uninterpreted identifier, e.g. TEXT-UTF8-TRIM in the grammar." > > The problem is that if the In-Reply-To header is: > In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com > > then this will resolve as a single call-id not two separate ones. > > would it not be possible to say make call-id a quoted-string??? > This may make little sense for the Call-ID header but it solves the problem here. > what would we then compare on though? could escaped values get in here which would > stop the efficient byte by byte equality checking that TEXT-UTF8-TRIM provided? This raises a broader issue. I see no reason why call-IDs should need to be escaped in some uses, i.e., allowing any UTF-8 string seems overkill. Call-IDs are just random identifiers not human-generated text, so there's no reason to allow commas, etc. Allowing "strange" characters just makes it more difficult for log files and anywhere else they might appear. Indeed, earlier we had agreed to use 'token' | 'token' @ 'token' or something like that as the appropriate BNF entity. -- 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 May 17 18:17:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11849 for ; Wed, 17 May 2000 18:17:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DBD9C44359; Wed, 17 May 2000 18:09:32 -0400 (EDT) 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 773E544337 for ; Wed, 17 May 2000 18:09:25 -0400 (EDT) Received: from dwillis (dwillis5.directlink.net [63.64.250.86]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id EAA08242; Thu, 18 May 2000 04:18:41 -0500 From: "Dean Willis" To: "IETF SIP" , "Michael Thomas" Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) Date: Wed, 17 May 2000 17:16:02 -0500 Message-ID: <003201bfc04d$7cdf7fa0$56fa403f@directlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2615.200 In-Reply-To: <14626.54617.648412.299580@thomasm-u1.cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id SAA11849 Comments inline Mike ponders: > Dean Willis writes: > > Actually, I think there might be an exception. Let's say we > have a large network that mixes several DiffServe classes -- for > simplicity, let's say "best effort" and "priority" clases. Assume > that there is normally a relatively high ratio of best-effort to > priority traffic in the network. > > > > One might a heuristic for traffic engineering that works like this: > > > > Assume a network monitoring system that can > > provide both a rough estimate of the ration of > > best-effort to priority traffic on the backbone > > and on specific links. Feed this data into access > > proxies. > > Doesn't this violate the law of "You are not > alone"? We're not making assurances -- we're making guesses about the state of the network. The question: Does the core network look like it will support another EF flow right now? The law of large numbers provides an averaging effect here. Remember, this is a big, densely-connected core. > > Besides, even if it were just EF RTP traffic > controlled by SIP proxies, how would they > synchronize amongst themselves? They don't need to. One call makes little difference to the core network. We just define the admissions threshold well into the "safe" area. Statistical distribution takes care of the rest. > > Even with the implicit linkage model of > signaling and admission authorization of > DQoS, it's still the edge routers making the > admission control decision from a "can we > support the bandwidth" standpoint into the > diffserv cloud. Different edge -- it's the edge of carrier network vs. the edge of customer network. And the feedback is through network management to SIP, and it could be completely decoupled from a DQOS. Consider it in an aggregation model, like a donut. The chewy outside parts of the donut are controlled by IntServ. Traffic leaps across the DiffServ donut-hole only if the heuristic process thinks (IE, is reasonably sure) that there is adequate bandwidth. -- Dean ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Wed May 17 21:49:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14090 for ; Wed, 17 May 2000 21:49:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2664E4433A; Wed, 17 May 2000 21:42:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id 2A73844337 for ; Wed, 17 May 2000 21:42:07 -0400 (EDT) Received: from ipunity.com (w226.z208176132.sjc-ca.dsl.cnc.net [208.176.132.226]) by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id UAA28758; Wed, 17 May 2000 20:48:59 -0500 Message-ID: <39234C5D.6C20D8B8@ipunity.com> Date: Wed, 17 May 2000 18:50:21 -0700 From: jimmy Zhang X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/alternative; boundary="------------AD3DAA1ECC8F6D032328A73C" Subject: [SIP] another SIP question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------AD3DAA1ECC8F6D032328A73C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, My question concerns the following scenario: When user A calls user B, the proxy server would forward the request to user B, in case user B is not available, the proxy server might opt to put the call to user B's mailbox. My question is that how does the mailbox know whom the incoming call is intended for, is there an existing field to hold the information? regards, -- Jimmy zhang (jz@ipunity.com) Software Engineer --------------AD3DAA1ECC8F6D032328A73C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

    My question concerns the following scenario: When user A calls user B,  the proxy server would forward the request to user B, in case user B is not available, the proxy server might opt to put the call to user B's mailbox. My question is that how does the mailbox
know whom the incoming call is intended for, is there an existing  field to hold the information?

   regards,
 
  

-- Jimmy zhang (jz@ipunity.com)

   Software Engineer
  --------------AD3DAA1ECC8F6D032328A73C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 01:23:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18423 for ; Thu, 18 May 2000 01:23:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 384CC44345; Thu, 18 May 2000 01:15:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 10AC944337 for ; Thu, 18 May 2000 01:15:27 -0400 (EDT) Received: from dynamicsoft.com (1Cust165.tnt1.freehold.nj.da.uu.net [63.17.113.165]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA28875; Thu, 18 May 2000 01:20:07 -0400 (EDT) Message-ID: <39238002.E53C2169@dynamicsoft.com> Date: Thu, 18 May 2000 01:30:42 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Gethin Liddell , Sip Mail List Subject: Re: [SIP] Problem with definition of In-Reply-To grammar References: <00051713145204.06188@gethin> <39230E0D.84818A9C@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > The problem is that if the In-Reply-To header is: > > In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com > > > > then this will resolve as a single call-id not two separate ones. > > > > would it not be possible to say make call-id a quoted-string??? > > This may make little sense for the Call-ID header but it solves the problem here. > > what would we then compare on though? could escaped values get in here which would > > stop the efficient byte by byte equality checking that TEXT-UTF8-TRIM provided? > > This raises a broader issue. I see no reason why call-IDs should need to > be escaped in some uses, i.e., allowing any UTF-8 string seems overkill. > Call-IDs are just random identifiers not human-generated text, so > there's no reason to allow commas, etc. Allowing "strange" characters > just makes it more difficult for log files and anywhere else they might > appear. > > Indeed, earlier we had agreed to use 'token' | 'token' @ 'token' or > something like that as the appropriate BNF entity. I agree completely. There is no reason to make life more complicated here. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 18 01:41:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20546 for ; Thu, 18 May 2000 01:41:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D7C9B4436F; Thu, 18 May 2000 01:33:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B2E8C44337 for ; Thu, 18 May 2000 01:33:51 -0400 (EDT) Received: from dynamicsoft.com (1Cust165.tnt1.freehold.nj.da.uu.net [63.17.113.165]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA28892; Thu, 18 May 2000 01:42:02 -0400 (EDT) Message-ID: <39238524.A3263087@dynamicsoft.com> Date: Thu, 18 May 2000 01:52:36 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Giuseppe Ricagni Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Giuseppe Ricagni wrote: > > I think we are talking about two different things. > I was just sayng that, according to Henning's model, to put it very simple, when you change > IP address you shuld send an Invite to your correspondent host containing your new IP > address (plus re-registering with your proxy, to allow for signalling to be sent to the new > address). > > If we assume (by hipotesys) that all SIP messages must go through at least 1 proxy, and if > we have an active conversation between two Italian mobiles located in Australia, the so > called "handoff delay" is one RTT between Australia and Italy, which can be something like > 300 msec or (very likely) more. > Even with a 300msec figure, you would en up losing some 15 voice samples, which is something > definetly undesirable. > > OTOH, with a local proxy, you wouldn' t lose more than 1 or, at worst, two samples. This presumes that there aren't any other proxies which decide to record-route. When a call is made, it will generally pass through many proxies, each providing differing levels of service. Some of these will want to record-route. I don't want to prevent them from doing so. Optimizing a system for the special case where (1) both caller and called party have home domains that are far, (2) they are both roaming in visiting domains that are close, (3) there are no other proxies on the path which record-route, seems like you are optimizing for the wrong case. Your assumption is also that handover is done through a re-INVITE to the new address once its known. This need not be the case. In a scenario with a smoother handover, I can imagine a brief period where the roaming mobile has both addresses - one in the old domain, one in the new. When it obtains the new one, it does a re-INVITE to *add* a new media stream targeted to the new address. This means it will get both stream of packets during this transition period. Once these new packets start arriving, it can do a re-INVITE again, turning off the stream targeted to the old address. It can then release the old address. I admit ignorance in not knowing if such a smooth handover at the IP level is possible. But, if so, it completely decouples the signaling RTT from any packet loss during handovers. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 18 01:46:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21025 for ; Thu, 18 May 2000 01:46:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D9FDC443AE; Thu, 18 May 2000 01:38:41 -0400 (EDT) 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 4FE33443AD for ; Thu, 18 May 2000 01:38:39 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 18 01:44:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id F2A2C44344; Thu, 18 May 2000 01:31:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C82F644341 for ; Thu, 18 May 2000 01:31:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 427A752C4; Thu, 18 May 2000 01:31:25 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5E74C52B6 for ; Thu, 18 May 2000 01:31:22 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 18 01:29:43 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu May 18 01:29:38 EDT 2000 Received: from dynamicsoft.com (1Cust165.tnt1.freehold.nj.da.uu.net [63.17.113.165]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA28883; Thu, 18 May 2000 01:30:36 -0400 (EDT) Message-ID: <39238277.963763CC@dynamicsoft.com> Date: Thu, 18 May 2000 01:41:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vakil, Mohammad" Cc: sip@lists.research.bell-labs.com, "'Mohammad.Vakil@outreachtech.com'" Subject: Re: [SIP] Multimedia Conferencing using SIP References: <410B13D70EB2D211827E00E0291E9FF7B2BCF4@ORT-MAIL> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Vakil, Mohammad" wrote: > > I read in RFC2543bis, "SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conference control protocols." This is a little confusing because in Abstract of RFC2543bis I read that these sessions(which are created, modified, and terminated using SIP), could also be Internet multimedia conferences..... Don't confuse multimedia conferences (i.e., voice plus video muliparty things) and conference control services. The latter include, as the bis draft states, floor control (who can talk now), and voting. SIP doesn't do conference control, but it can certainly initiate multimedia multiparty sessions. > > I skimmed through the document "Distributed Multipoint Conferences using SIP"(draft-mark-sip-dmcs-00). I've a situation where a central server does all the conferencing and I'd like SIP UACs to be able to estabilish a multimedia conference session on that server. e.g. for a conference call, they can specify hostname or IP address of the Conferencing Sever in the SDP and establish the session. > Do we have an extension or something, which explains Conferencing on a central server? Any pointers, explanations, or directions would very appreciated. No extensions needed for central conference servers. It works just like it does in the PSTN - you dial a number which corresponds to a port on a bridge. In the case of SIP, you would INVITE to a URL corresponding to a port on the conference server, like sip:conference33287372@mcu.com. The result appears as a point to point SIP call as far as your UA is concerned, but the server is mixing media and sending the mixed media to your UA. You will learn the identity of the other participants through RTCP CSRC. How do you know the right URL to send an INVITE to? Well, how do you know what number to dial for a conference in PSTN? You're told out of band. URLs can be included in emails, web pages, whatever. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 18 05:23:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01409 for ; Thu, 18 May 2000 05:23:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF92F4434F; Thu, 18 May 2000 05:16:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mushroom.icoe.net (icoe-gate.icoe.att.nl [194.242.71.50]) by lists.bell-labs.com (Postfix) with ESMTP id E80804433A for ; Thu, 18 May 2000 05:16:05 -0400 (EDT) Received: by mushroom.icoe.net; id LAA08221; Thu, 18 May 2000 11:25:15 +0200 (CEST) Received: from unknown(135.76.170.11) by mushroom.icoe.net via smap (4.0a) id xma008216; Thu, 18 May 00 11:24:44 +0200 Received: from blackberry (mikan.icoe.att.com [135.76.170.4]) by watermelon.icoe.att.com (Postfix) with ESMTP id 1062811581; Thu, 18 May 2000 11:22:31 +0200 (MET DST) Message-Id: <4.2.0.58.20000518111830.02e429c0@watermelon.icoe.att.com> X-Sender: romeo@watermelon.icoe.att.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 18 May 2000 11:22:17 +0200 To: Henning Schulzrinne From: Romeo Zwart Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide Cc: sip@lists.bell-labs.com In-Reply-To: <3922C124.4C3803E9@cs.columbia.edu> References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <4.1.20000517090137.00a58290@localhost> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Henning, At 11:56 AM 17-05-00 -0400, you wrote: >Just as a data point: Tony Eyers and I have looked at signaling >performance under redirect and proxy assumptions, for both ("optimized") >TCP and UDP. See the paper in the IPtel 2000 workshop at >http://www.fokus.gmd.de/events/iptel2000/pg.php3 These measurements did not include the PRACK model. Do you know if anyone is working on a followup that addresses the reliable provisional response model as well? >This is based on recent real Internet measurements, assuming that SIP >will not use either reserved flows or BBE diff-serv classes. If one were >to use standard TCP with its long initial retransmit timer, things get >really bad (we didn't look at this since it's too bad to be >interesting...), but even with cross-country redirection, call setup >delays are rather modest. Note that we looked at percentiles, not >averages. This is a very interesting simulation. Has a more detailed analysis of these results been published? Some of the results seem rather counter-intuitive. For example, if you compare graphs 12 (simple call NY-Chi) and 14 (redirect, NY-West Coast), the minimum setup delay roughly triples. Considering the combined effect of the added redirect and the larger distance, this is a trend you might expect, albeit a rather large increase. Comparing the same graphs on the 95 percentile scores, the result seems to be that variation increases a lot, which again seems to make sense. However the graphs also suggests that the trend is downward, rather than upward, i.e. from roughly 600 ms in the simple call case, down to 200 ms on many of the observed days for the redirected Coast-to-Coast case. Romeo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 07:27:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02610 for ; Thu, 18 May 2000 07:27:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A0CF34433A; Thu, 18 May 2000 07:19:49 -0400 (EDT) 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 1106D44337 for ; Thu, 18 May 2000 07:19:47 -0400 (EDT) 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 HAA28896; Thu, 18 May 2000 07:27:08 -0400 (EDT) Message-ID: <3923D38C.E2AB4340@cs.columbia.edu> Date: Thu, 18 May 2000 07:27:08 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Romeo Zwart Cc: sip@lists.bell-labs.com, Tony Eyers Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <4.1.20000517090137.00a58290@localhost> <4.2.0.58.20000518111830.02e429c0@watermelon.icoe.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Romeo Zwart wrote: > > Hi Henning, > > At 11:56 AM 17-05-00 -0400, you wrote: > >Just as a data point: Tony Eyers and I have looked at signaling > >performance under redirect and proxy assumptions, for both ("optimized") > >TCP and UDP. See the paper in the IPtel 2000 workshop at > >http://www.fokus.gmd.de/events/iptel2000/pg.php3 > > These measurements did not include the PRACK model. Do you > know if anyone is working on a followup that addresses the reliable > provisional response model as well? Not that I know of, but PRACK would seem to be a fairly limited-use model. You'd have to address also the whole QoS setup mechanism, I suppose... > > This is a very interesting simulation. Has a more detailed analysis > of these results been published? Some of the results seem rather > counter-intuitive. Not sure if you looked at the paper or the slides, but the paper is about as complete as we have at this point. > > For example, if you compare graphs 12 (simple call NY-Chi) and 14 > (redirect, NY-West Coast), the minimum setup delay roughly triples. > Considering the combined effect of the added redirect and the larger > distance, this is a trend you might expect, albeit a rather large increase. > Comparing the same graphs on the 95 percentile scores, the result > seems to be that variation increases a lot, which again seems to > make sense. However the graphs also suggests that the trend is > downward, rather than upward, i.e. from roughly 600 ms in the > simple call case, down to 200 ms on many of the observed days > for the redirected Coast-to-Coast case. Tony, want to comment? -- 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 May 18 08:07:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03613 for ; Thu, 18 May 2000 08:07:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C76744350; Thu, 18 May 2000 07:59:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mhz.elec.uow.edu.au (mhz.elec.uow.edu.au [130.130.88.88]) by lists.bell-labs.com (Postfix) with ESMTP id AC7AC44337 for ; Thu, 18 May 2000 07:59:44 -0400 (EDT) Received: from mobile3 (purcell.elec.uow.edu.au [130.130.88.103]) by mhz.elec.uow.edu.au (8.9.3/8.9.3) with SMTP id WAA31869; Thu, 18 May 2000 22:14:09 +1000 Message-Id: <3.0.6.32.20000518220519.009db100@elec.uow.edu.au> X-Sender: tony@elec.uow.edu.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 18 May 2000 22:05:19 +1000 To: Henning Schulzrinne , Romeo Zwart From: tony@elec.uow.edu.au Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide Cc: sip@lists.bell-labs.com In-Reply-To: <3923D38C.E2AB4340@cs.columbia.edu> References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <4.1.20000517090137.00a58290@localhost> <4.2.0.58.20000518111830.02e429c0@watermelon.icoe.att.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Romeo, Henning, As you say, the results that you mention appear counter-intuitive. A detailed discussion appears in section VII of the paper. However, the reason for the apparent discrepancy (i.e. the New York-Chicago path having a higher 95th delay percentile than the longer New York-West Coast one) is the consistently higher error rates seen on the New York-Chicago path. These errors cause SIP timeouts, and hence push the 95th percentile over 500 msec. As you mention, the graphs show minimum delays which reflect the respective propagation delays expected over the two paths. The 95th percentile results show two features: the delay arising from the 500 msec SIP timeouts, and the delay arising from queueing variations (e.g. the results around 200-300 msec on the New York-West Coast graph). In general, the 95th percentile of the call setup delay is greatly influenced by the prevailing error rate. We also do show that increasing the number of hops in the call setup path can greatly increase the 95th delay percentile (e.g. figures 9 and 10 from the paper). Hope this helps. Regards, Tony At 07:27 AM 5/18/00 -0400, Henning Schulzrinne wrote: >Romeo Zwart wrote: >> >> Hi Henning, >> >> At 11:56 AM 17-05-00 -0400, you wrote: >> >Just as a data point: Tony Eyers and I have looked at signaling >> >performance under redirect and proxy assumptions, for both ("optimized") >> >TCP and UDP. See the paper in the IPtel 2000 workshop at >> >http://www.fokus.gmd.de/events/iptel2000/pg.php3 >> >> These measurements did not include the PRACK model. Do you >> know if anyone is working on a followup that addresses the reliable >> provisional response model as well? > >Not that I know of, but PRACK would seem to be a fairly limited-use >model. You'd have to address also the whole QoS setup mechanism, I >suppose... > > >> >> This is a very interesting simulation. Has a more detailed analysis >> of these results been published? Some of the results seem rather >> counter-intuitive. > >Not sure if you looked at the paper or the slides, but the paper is >about as complete as we have at this point. > >> >> For example, if you compare graphs 12 (simple call NY-Chi) and 14 >> (redirect, NY-West Coast), the minimum setup delay roughly triples. >> Considering the combined effect of the added redirect and the larger >> distance, this is a trend you might expect, albeit a rather large increase. >> Comparing the same graphs on the 95 percentile scores, the result >> seems to be that variation increases a lot, which again seems to >> make sense. However the graphs also suggests that the trend is >> downward, rather than upward, i.e. from roughly 600 ms in the >> simple call case, down to 200 ms on many of the observed days >> for the redirected Coast-to-Coast case. > >Tony, want to comment? >-- >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 May 18 08:45:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04420 for ; Thu, 18 May 2000 08:45:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C5A944385; Thu, 18 May 2000 08:37:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 182AD44337 for ; Thu, 18 May 2000 08:37:36 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id OAA02502 for ; Thu, 18 May 2000 14:43:39 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id OAA17704 for ; Thu, 18 May 2000 14:42:20 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id OAA22016 for ; Thu, 18 May 2000 14:42:37 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA3984; Thu, 18 May 2000 14:52:35 +0200 Message-ID: <3923E6CA.941FA323@italtel.it> Date: Thu, 18 May 2000 14:49:14 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> <39238524.A3263087@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------FC6D76027E7D29F668A93CDE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------FC6D76027E7D29F668A93CDE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Giuseppe Ricagni wrote: > > > > > I think we are talking about two different things. > > I was just sayng that, according to Henning's model, to put it very simple, when you change > > IP address you shuld send an Invite to your correspondent host containing your new IP > > address (plus re-registering with your proxy, to allow for signalling to be sent to the new > > address). > > > > If we assume (by hipotesys) that all SIP messages must go through at least 1 proxy, and if > > we have an active conversation between two Italian mobiles located in Australia, the so > > called "handoff delay" is one RTT between Australia and Italy, which can be something like > > 300 msec or (very likely) more. > > Even with a 300msec figure, you would en up losing some 15 voice samples, which is something > > definetly undesirable. > > > > OTOH, with a local proxy, you wouldn' t lose more than 1 or, at worst, two samples. > > This presumes that there aren't any other proxies which decide to > record-route. When a call is made, it will generally pass through many > proxies, each providing differing levels of service. Some of these will > want to record-route.I don't want to prevent them from doing so. Basically, the only problem here is that the callee is roaming. As Henning reminded us, this requires a database (let' s call it Home Subscriber Server: HSS, a kind of GSM HLR) lookup by the "calling proxy" in the callee home domain, to have information about the address of the proxy the callee is registered at. This lookup can be performed directly by the caller proxy, or via a callee home domain "home proxy". This "home proxy" is the only proxy you would like to write in the record-route and I would like not to. IMHO, since from a technical point of view you could query the HSS directly from the calling proxy, you are to involving the "home proxy" only for "political reasons", to some extent to "filter" queries to the HSS. There is therefore no point in having such proxy in the record-route. Also remember we are talking here about basic calls, requesting no additional services, or services that are user profile independent. More complex scenarios can be achieved, as I suggested in a previous posting: there are four kind of value added services: a) those who require user profile information b) those who don' t require user profile information, but to some extent they are not supported by the visited domain c) those who don' t require user profile information and they are implemented by the visited domain. d) null services: in other words, basic calls that do not request any kind of value added service Case a) and b) require some kind of interaction with the home network. C) and d) don' t. [....] type a) services. need to execute it in the home network, unless you download the user profile at registration time AND the visited network has implemented that specific service. With respect to the method used to classify service request within the four cathegories, a possibility is that the home domain, at registration time, sends information to the visited domain on the requirements to meet to locally execute a given set of services for that specific user. If the visited domain supports such requirements ==> those services can be executed locally. This mechanism can even be extended to the full download of the user profile. > Optimizing a system for the special case where (1) both caller and > called party have home domains that are far, (2) they are both roaming > in visiting domains that are close, (3) there are no other proxies on > the path which record-route, seems like you are optimizing for the wrong > case. First of all: we are not "optimizing" a system, here: we are adding a feature, that can be useful to "optimize" a given set of cases. Let's make a simpler (and very common) example: an Italian mobile roaming to Australia, that wants to call a (local !) Taxy: is this the wrong case ? (In that case I'm wrong myself, because I did it in Adelaide!!! :-)) It is a basic call, no supplementary services required, it can definetly handled locally. The calle is a PSTN number, therefore no HSS lookup is neded (well, even if the calee was an australian mobile phone, it would have been a local -Australian- lookup of the Australian HSS). Why should I send my Invite to Italy ?!?!? > Your assumption is also that handover is done through a re-INVITE to the > new address once its known. well, something like that. (the Invite is sent FROM the mobile host -the one changing address- towards its correspondent) > This need not be the case. In a scenario > with a smoother handover, I can imagine a brief period where the roaming > mobile has both addresses - one in the old domain, one in the new. When > it obtains the new one, it does a re-INVITE to *add* a new media stream > targeted to the new address. This means it will get both stream of > packets during this transition period. Once these new packets start > arriving, it can do a re-INVITE again, turning off the stream targeted > to the old address. It can then release the old address. Sorry, but I think you missed the target. The problem is only related to the in-flight packets. If I' m in the position of keeping the two address active for a while, I will get the in-flight packets on the old address anyway !!!! I don' t need any duplicte invite !!! The problem comes when I lose the old address and there are some already in-flight packets addressed to it. The number of in-flight packets is proportional to the time needed to make the other endpoint aware of the new address. No duplicate Invites or whatever can help. Giuseppe > > I admit ignorance in not knowing if such a smooth handover at the IP > level is possible. But, if so, it completely decouples the signaling RTT > from any packet loss during handovers. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- --------------FC6D76027E7D29F668A93CDE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote:
Giuseppe Ricagni wrote:
>

> I think we are talking about two different things.
> I was just sayng that, according to Henning's model, to put it very simple, when you change
> IP address you shuld send an Invite to your correspondent host containing your new IP
> address (plus re-registering with your proxy, to allow for signalling to be sent to the new
> address).
>
> If we assume (by hipotesys) that all SIP messages must go through at least 1 proxy, and if
> we have an active conversation between two Italian mobiles located in Australia, the so
> called "handoff delay" is one RTT between Australia and Italy, which can be something like
> 300 msec or (very likely) more.
> Even with a 300msec figure, you would en up losing some 15 voice samples, which is something
> definetly undesirable.
>
> OTOH, with a local proxy, you wouldn' t lose more than 1 or, at worst, two samples.

This presumes that there aren't any other proxies which decide to
record-route. When a call is made, it will generally pass through many
proxies, each providing differing levels of service. Some of these will
want to record-route.I don't want to prevent them from doing so.


Basically, the only problem here is that the callee is roaming.

As Henning reminded us, this requires a database (let' s call it Home Subscriber Server: HSS, a kind of GSM HLR) lookup by the "calling proxy" in the callee home domain, to have information about the address of the proxy the callee is registered at.

This lookup can be performed directly by the caller proxy, or via a callee home domain "home proxy".

This  "home proxy" is the only proxy you would like to write in the record-route and I would like not to.

IMHO, since  from a technical point of view you could query the HSS directly from the calling proxy, you are to involving the "home proxy" only for "political reasons", to some extent to "filter" queries to the HSS.

There is therefore no point in having  such proxy in the record-route.

Also remember we are talking here about basic calls, requesting no additional services, or services that   are user profile independent. More complex scenarios can be achieved, as I suggested in a previous posting:
 

there are four kind of value added services:

     a) those who require user profile information
     b) those who don' t  require user profile information, but to some extent they are not
     supported by the visited domain
     c) those who don' t  require user profile information and they are implemented by the
     visited domain.
     d) null services: in other words, basic calls that do not request any kind of value added
     service

Case a) and b) require some kind of interaction with the home network.

C) and d) don' t.

[....]

type a) services. need to execute it in the home network, unless you download
the user profile at registration time AND the visited network has implemented that specific
service.

With respect to the method used to classify service request within the four cathegories, a
possibility is that  the home domain, at registration time, sends information to the visited domain
on the requirements to meet  to locally execute a given set of services for that specific user. If
the visited domain supports such requirements ==> those services can be executed locally.

This mechanism can even  be extended to the full download of the user profile.
 

Optimizing a system for the special case where (1) both caller and
called party have home domains that are far, (2) they are both roaming
in visiting domains that are close, (3) there are no other proxies on
the path which record-route, seems like you are optimizing for the wrong
case.
First of all: we are not "optimizing" a system, here: we are adding a feature, that can be useful to "optimize" a given set of cases.

Let's make a simpler  (and very common) example:
an Italian mobile roaming to Australia, that wants to call a (local !) Taxy: is this the wrong case ? (In that case I'm wrong myself, because I did it in Adelaide!!!  :-))

It is a basic call, no supplementary services required, it can definetly handled locally. The calle is a PSTN number, therefore no HSS lookup is neded (well, even if the calee was an australian mobile phone, it would have been a local -Australian- lookup of the Australian HSS).
Why should I send my Invite to Italy ?!?!?
 

Your assumption is also that handover is done through a re-INVITE to the
new address once its known.
well, something like that. (the Invite is sent FROM the mobile host -the one changing address- towards its correspondent)
This need not be the case. In a scenario
with a smoother handover, I can imagine a brief period where the roaming
mobile has both addresses - one in the old domain, one in the new. When
it obtains the new one, it does a re-INVITE to *add* a new media stream
targeted to the new address. This means it will get both stream of
packets during this transition period. Once these new packets start
arriving, it can do a re-INVITE again, turning off the stream targeted
to the old address. It can then release the old address.
Sorry, but I think you missed the target.

The problem is only related to the in-flight packets.
If I' m in the position of keeping the two address active for a while, I will get the in-flight packets on the old
address anyway !!!! I don' t need any duplicte invite !!!

The problem comes when I lose the old address and there are some already in-flight packets addressed to it.
The number of in-flight packets is proportional to the time needed to make  the other endpoint aware of the new address.
No duplicate Invites or whatever can help.

Giuseppe

 
I admit ignorance in not knowing if such a smooth handover at the IP
level is possible. But, if so, it completely decouples the signaling RTT
from any packet loss during handovers.

-Jonathan R.

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

--
----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------
  --------------FC6D76027E7D29F668A93CDE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 09:12:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04733 for ; Thu, 18 May 2000 09:12:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EA954433C; Thu, 18 May 2000 09:04:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mushroom.icoe.net (icoe-gate.icoe.att.nl [194.242.71.50]) by lists.bell-labs.com (Postfix) with ESMTP id 8BE1D44337 for ; Thu, 18 May 2000 09:04:50 -0400 (EDT) Received: by mushroom.icoe.net; id PAA13607; Thu, 18 May 2000 15:14:17 +0200 (CEST) Received: from unknown(135.76.170.11) by mushroom.icoe.net via smap (4.0a) id xma013594; Thu, 18 May 00 15:13:59 +0200 Received: from blackberry (mikan.icoe.att.com [135.76.170.4]) by watermelon.icoe.att.com (Postfix) with ESMTP id AFC0211581; Thu, 18 May 2000 15:11:48 +0200 (MET DST) Message-Id: <4.2.0.58.20000518142745.00c69f00@watermelon.icoe.att.com> X-Sender: romeo@watermelon.icoe.att.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 18 May 2000 15:11:29 +0200 To: From: Romeo Zwart Subject: SIP Signalling delays (was Re: [SIP] Minutes of SIP Security task force in Adelaide) Cc: Henning Schulzrinne , sip@lists.bell-labs.com In-Reply-To: <3.0.6.32.20000518220519.009db100@elec.uow.edu.au> References: <3923D38C.E2AB4340@cs.columbia.edu> <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <4.1.20000517090137.00a58290@localhost> <4.2.0.58.20000518111830.02e429c0@watermelon.icoe.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Henning, Tony, Thanks for your explanations on the graphs. I admit having only seen the presentation, not the paper. The proceedings are rather difficult to obtain from the fokus website - I've restarted several download attempts today, without much success. Could you forward me a copy of the paper directly? At 10:05 PM 18-05-00 +1000, tony@elec.uow.edu.au wrote: [... stuff deleted ...] >As you mention, the graphs show minimum delays which >reflect the respective propagation delays expected over the >two paths. The 95th percentile results show two >features: the delay arising from the 500 msec SIP timeouts, >and the delay arising from queueing variations >(e.g. the results around 200-300 msec on the New York-West >Coast graph). OK, so the 500 ms timeout explains the 'quatum leap' effect seen in the graphs - instead of a smooth distribution of setup times. Which may suggest that packet loss contributes significantly, even more than (queuing and propagation) delay itself. >In general, the 95th percentile of the call setup delay >is greatly influenced by the prevailing error rate. We also >do show that increasing the number of hops in the call >setup path can greatly increase the 95th delay percentile >(e.g. figures 9 and 10 from the paper). If there is a correlation with the number of (router)hops, this also suggests packet loss as a contributor, although queuing delay can't be ignored, ofcourse. I am very interested to have a look at your paper. Regards, Romeo >Regards, > >Tony _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 09:26:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05072 for ; Thu, 18 May 2000 09:26:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A8FF44358; Thu, 18 May 2000 09:18:58 -0400 (EDT) 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 8E40944337 for ; Thu, 18 May 2000 09:18:55 -0400 (EDT) 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 JAA04538; Thu, 18 May 2000 09:26:12 -0400 (EDT) Message-ID: <3923EF74.A817ED@cs.columbia.edu> Date: Thu, 18 May 2000 09:26:12 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Romeo Zwart Cc: tony@elec.uow.edu.au, sip@lists.bell-labs.com Subject: Re: SIP Signalling delays (was Re: [SIP] Minutes of SIP Securitytask force in Adelaide) References: <3923D38C.E2AB4340@cs.columbia.edu> <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <4.1.20000517090137.00a58290@localhost> <4.2.0.58.20000518111830.02e429c0@watermelon.icoe.att.com> <4.2.0.58.20000518142745.00c69f00@watermelon.icoe.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I've added the paper reference to http://www.cs.columbia.edu/~hgs/sip/papers.html and http://www.cs.columbia.edu/~hgs/research/imm/ Thanks for your interest. -- 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 May 18 10:13:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07142 for ; Thu, 18 May 2000 10:13:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F043344356; Thu, 18 May 2000 10:05:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6354544337 for ; Thu, 18 May 2000 10:05:49 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA29476; Thu, 18 May 2000 10:14:28 -0400 (EDT) Message-ID: <3923FD41.2C969D10@dynamicsoft.com> Date: Thu, 18 May 2000 10:25:05 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jimmy Zhang Cc: sip@lists.bell-labs.com Subject: Re: [SIP] another SIP question References: <39234C5D.6C20D8B8@ipunity.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit jimmy Zhang wrote: > > Hello, > > My question concerns the following scenario: When user A calls > user B, the proxy server would forward the request to user B, in case > user B is not available, the proxy server might opt to put the call to > user B's mailbox. My question is that how does the mailbox > know whom the incoming call is intended for, is there an existing > field to hold the information? The To field of the request always holds the original recipient the call was destined for. It remains unchanged as the request is forwarded through the network. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 18 11:27:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08704 for ; Thu, 18 May 2000 11:27:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 95C744435F; Thu, 18 May 2000 11:19:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhost.ttimail.com (mailhost.ttimail.com [209.136.128.4]) by lists.bell-labs.com (Postfix) with SMTP id C190E44337 for ; Thu, 18 May 2000 11:19:47 -0400 (EDT) Received: From MAILHOST.TTIMAIL.COM (10.10.100.5[10.10.100.5 port:4475]) by mailhost.ttimail.com Mail essentials (server 2.422) with SMTP id: <528@mailhost.ttimail.com> for ; Thu, 18 May 2000 10:26:36 AM -0500 smtpmailfrom Received: by mailhost.tti.net with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 10:26:36 -0500 Message-ID: From: Kevin Summers To: sip@lists.bell-labs.com Subject: [SIP] Payload Boundary of ISUP Object? Date: Thu, 18 May 2000 10:26:35 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com In draft-ietf-sip-isup-mime-01.txt, it is not explicitly stated where encapsulation of an ISUP message should begin. It seems logical to begin with the message type (as the example in the draft shows), but nowhere does the draft prescribe exactly where to start. I don't think that this decision should to be left to the implementors -- perhaps we should strengthen the requirements of how the message is encapsulated. Any thoughts? Kevin Summers message scanned for virus content. telecom technologies, inc. http://www.ttiweb.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 May 18 12:41:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10256 for ; Thu, 18 May 2000 12:41:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F16D74434B; Thu, 18 May 2000 12:33:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by lists.bell-labs.com (Postfix) with ESMTP id 1A08A44337 for ; Thu, 18 May 2000 12:33:21 -0400 (EDT) Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id LAA19117; Thu, 18 May 2000 11:40:11 -0500 (CDT) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 862568E3.005BC98D ; Thu, 18 May 2000 11:42:33 -0500 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Burcak Beser" To: sip@lists.bell-labs.com Message-ID: <862568E3.005BC7B8.00@mwgate02.mw.3com.com> Date: Thu, 18 May 2000 11:42:28 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Media Authorization Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I am in the process of updating the "SIP Extensions for Media Authorization" draft ( http://search.ietf.org/internet-drafts/draft-dcsgroup-sip-call-auth-01.txt). Since there were no comments during IETF meeting and in the mailing list, I am only planning to make some editorial cleaning and correct section 10 compliance. If you have any questions and/or suggestions please let me know. Burcak Beser Burcak_Beser@3Com.com 3Com Carrier Systems Group _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 12:59:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10477 for ; Thu, 18 May 2000 12:59:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4278844395; Thu, 18 May 2000 12:51:56 -0400 (EDT) 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 7181A44337 for ; Thu, 18 May 2000 12:51:53 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29301; Thu, 18 May 2000 09:55:58 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26173; Thu, 18 May 2000 09:55:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14628.8344.56504.279408@thomasm-u1.cisco.com> Date: Thu, 18 May 2000 09:55:52 -0700 (PDT) To: Giuseppe Ricagni Cc: Jonathan Rosenberg , Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <3923E6CA.941FA323@italtel.it> References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> <39238524.A3263087@dynamicsoft.com> <3923E6CA.941FA323@italtel.it> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Giuseppe Ricagni writes: > Basically, the only problem here is that the callee is roaming. > > As Henning reminded us, this requires a database (let' s call it Home Subscriber Server: HSS, a > kind of GSM HLR) lookup by the "calling proxy" in the callee home domain, to have information > about the address of the proxy the callee is registered at. > > This lookup can be performed directly by the caller proxy, or via a callee home domain "home > proxy". Sorry to be flippant, but gag me with a spoon. If you remote the proxy, this presupposes that: 1) We have a standardized database transport protocol 2) [far worse] we have a standardized database scheme versus: going directly to my home proxy for which I do not need to expose a database transport protocol or a scheme at all. This is a no-brainer to me: having to standardize a database scheme will stiffle innovation and propogate the feature non-transparency brain damage of the current system. This is unacceptible. Let's take step back here though: the claimed reason for wanting a remote proxy is so that you don't incur a transport layer dog leg clear back to my home proxy half way around the world. However, I'll claim that that problem can be solved far more adequately by putting proxies geographically closer to the roamed user. I doubt that it is unreasonable to assume that AT&T, etc, can place a home proxy for my service physically on Australia just like anybody else. The only challenge is how my mobile unit gets directed toward a home proxy that is geographically close to me (thus helping round trip latencies). I'll claim that that is a useful problem to solve overall because web services, etc, have the identical problem. Maybe it's already solved for all I know. Even if it is not, I'd far rather work on that than have to come up with some grandiose, all encompassing database scheme. It is an intractable problem, and has many clear disadvantages for all parties. 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 May 18 14:31:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11798 for ; Thu, 18 May 2000 14:31:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 145794438D; Thu, 18 May 2000 14:24:14 -0400 (EDT) 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 17A5144379 for ; Thu, 18 May 2000 14:24:11 -0400 (EDT) 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 OAA29454; Thu, 18 May 2000 14:31:20 -0400 (EDT) Message-ID: <392436F8.F5A3995@cs.columbia.edu> Date: Thu, 18 May 2000 14:31:20 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Giuseppe Ricagni , Jonathan Rosenberg , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> <39238524.A3263087@dynamicsoft.com> <3923E6CA.941FA323@italtel.it> <14628.8344.56504.279408@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit As a point of reference, I do hope that (some) services will be portable across providers, if not for reasons of mobility, then for the ability to take them with you when you change providers. CPL has that aim. It would not be hard, as I indicated earlier, to have CPL scripts "roam" with the user, without all agreeing on the universal LDAP schema or database interface. Whether service providers will offer this feature is probably less a technical than a business issue. I don't think it's a good idea to rely on this being available, but service portability is a worthwhile goal independent of this application. If a set of providers agrees to support CPL, say, and then say "we switch your calls faster", why not? -- 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 May 18 14:45:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11889 for ; Thu, 18 May 2000 14:45:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2FD9C443AD; Thu, 18 May 2000 14:37:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 195B54439A for ; Thu, 18 May 2000 14:37:18 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id UAA26826 for ; Thu, 18 May 2000 20:43:28 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id UAA13036 for ; Thu, 18 May 2000 20:42:07 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id UAA16622 for ; Thu, 18 May 2000 20:42:28 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA4CA3; Thu, 18 May 2000 20:52:27 +0200 Message-ID: <39243B1F.E6ED1678@italtel.it> Date: Thu, 18 May 2000 20:49:03 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> <39238524.A3263087@dynamicsoft.com> <3923E6CA.941FA323@italtel.it> <14628.8344.56504.279408@thomasm-u1.cisco.com> Content-Type: multipart/alternative; boundary="------------23DF57763576BC8A139DFD1F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------23DF57763576BC8A139DFD1F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry Michael, I think we are diverging from the original issue. * When the callee is roaming, either you use a standardized database transport protocol or you delegate the callee home domain proxy to perform the query, but you have a RTT towards the callee home domain. Your solution of having synchronized copies of such database all over the world is another interesting enhancement, maybe expensive (pretty sure off-the-shelf solutions are already out there) o the point I was making was that for all subsequent mid-call messages, just like the INVITEs you have to send for handovers, you should shortcut and avoid the round trip to the home net. * When the caller is roaming, under certain circumstances (related to the type of value added services required & the set of services supported by the visited network & the possibility to transfer a user profile--see my previous messages) it is possible to avoid sending signalling back to the caller home domain. This applies to calls towards the fixed network (which may be routed by TRIP) and for calls to local mobiles. For roaming mobiles you fall back to the prvious case: still you don' t need to send signalling to the caller home domain, but you have a RTT to the callee home domain. Hope this can summarize the discussion Giuseppe Michael Thomas wrote: > Giuseppe Ricagni writes: > > Basically, the only problem here is that the callee is roaming. > > > > As Henning reminded us, this requires a database (let' s call it Home Subscriber Server: HSS, a > > kind of GSM HLR) lookup by the "calling proxy" in the callee home domain, to have information > > about the address of the proxy the callee is registered at. > > > > This lookup can be performed directly by the caller proxy, or via a callee home domain "home > > proxy". > > Sorry to be flippant, but gag me with a spoon. > > If you remote the proxy, this presupposes that: > > 1) We have a standardized database transport protocol > 2) [far worse] we have a standardized database scheme > > versus: > > going directly to my home proxy for which I do not > need to expose a database transport protocol or > a scheme at all. > > This is a no-brainer to me: having to standardize > a database scheme will stiffle innovation and > propogate the feature non-transparency brain damage > of the current system. This is unacceptible. > > Let's take step back here though: the claimed > reason for wanting a remote proxy is so that > you don't incur a transport layer dog leg clear > back to my home proxy half way around the > world. However, I'll claim that that problem > can be solved far more adequately by putting > proxies geographically closer to the roamed > user. I doubt that it is unreasonable to assume > that AT&T, etc, can place a home proxy for my > service physically on Australia just like > anybody else. > > The only challenge is how my mobile unit gets > directed toward a home proxy that is > geographically close to me (thus helping > round trip latencies). I'll claim that that > is a useful problem to solve overall because > web services, etc, have the identical problem. > > Maybe it's already solved for all I know. Even > if it is not, I'd far rather work on that than > have to come up with some grandiose, all > encompassing database scheme. It is an > intractable problem, and has many clear > disadvantages for all parties. > > Mike > > -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- --------------23DF57763576BC8A139DFD1F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry Michael,

I think we are diverging from the original issue.

  • When the callee is roaming, either you use a standardized database transport protocol or you delegate the callee home domain proxy to perform the query, but you have a RTT towards the callee home domain. Your solution of having synchronized copies of such database all over the world is another interesting enhancement, maybe expensive (pretty sure off-the-shelf solutions are already out there)
    • the point I was making was that for all subsequent mid-call messages, just like the INVITEs you have to send for handovers, you should shortcut and avoid the round trip to the home net.

     
  • When the caller is roaming, under certain circumstances (related to the type of value added services required & the set of services supported by the visited network &  the possibility to transfer a user profile--see my previous messages) it is possible to avoid sending signalling back to the caller home domain. This applies to calls towards the fixed network (which may be routed by TRIP) and for calls to local mobiles. For roaming mobiles you fall back to the prvious case: still you don' t need to send signalling to the caller home domain, but you have a RTT to the callee home domain.
Hope this can summarize the discussion

Giuseppe

Michael Thomas wrote:

Giuseppe Ricagni writes:
 > Basically, the only problem here is that the callee is roaming.
 >
 > As Henning reminded us, this requires a database (let' s call it Home Subscriber Server: HSS, a
 > kind of GSM HLR) lookup by the "calling proxy" in the callee home domain, to have information
 > about the address of the proxy the callee is registered at.
 >
 > This lookup can be performed directly by the caller proxy, or via a callee home domain "home
 > proxy".

   Sorry to be flippant, but gag me with a spoon.

   If you remote the proxy, this presupposes that:

   1) We have a standardized database transport protocol
   2) [far worse] we have a standardized database scheme

   versus:

   going directly to my home proxy for which I do not
   need to expose a database transport protocol or
   a scheme at all.

   This is a no-brainer to me: having to standardize
   a database scheme will stiffle innovation and
   propogate the feature non-transparency brain damage
   of the current system. This is unacceptible.

   Let's take step back here though: the claimed
   reason for wanting a remote proxy is so that
   you don't incur a transport layer dog leg clear
   back to my home proxy half way around the
   world. However, I'll claim that that problem
   can be solved far more adequately by putting
   proxies geographically closer to the roamed
   user. I doubt that it is unreasonable to assume
   that AT&T, etc, can place a home proxy for my
   service physically on Australia just like
   anybody else.

   The only challenge is how my mobile unit gets
   directed toward a home proxy that is
   geographically close to me (thus helping
   round trip latencies). I'll claim that that
   is a useful problem to solve overall because
   web services, etc, have the identical problem.

   Maybe it's already solved for all I know. Even
   if it is not, I'd far rather work on that than
   have to come up with some grandiose, all
   encompassing database scheme. It is an
   intractable problem, and has many clear
   disadvantages for all parties.

                    Mike
 
 

--
----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------
  --------------23DF57763576BC8A139DFD1F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 14:56:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11954 for ; Thu, 18 May 2000 14:56:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E1263443AB; Thu, 18 May 2000 14:48:37 -0400 (EDT) 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 47E9944337 for ; Thu, 18 May 2000 14:48:35 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 18 14:54:41 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 693D244344; Thu, 18 May 2000 14:41:31 -0400 (EDT) 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 2124E44341 for ; Thu, 18 May 2000 14:41:31 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA28078; Thu, 18 May 2000 13:41:28 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA28075; Thu, 18 May 2000 13:41:27 -0500 Message-ID: <39243951.FCC5DE10@lucent.com> Date: Thu, 18 May 2000 13:41:21 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) 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 URL clarification for user paramater Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan/Henning: In RFC2543bis, section 2, 2nd last paragraph on page 17, you say: "The user parameter value "np-queried" indicates that the user part contains a telephone number AND that the number reflects the result of a query to the local number portability database". However, in Figure 3 on page 18, the BNF for user-param is: user-param = "user="("phone" | "ip") Should it be modified to: user-param = "user="(("phone" | "np-queried") | "ip") A look at the archives indicate that Jonathan and Marc Petit-Huguenin had a thread on this around May 10, 2000 with Jonathan stating that there was no consensus on if this was the right way to do this. Any updates? Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 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 May 18 15:25:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12154 for ; Thu, 18 May 2000 15:25:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7CC724439A; Thu, 18 May 2000 15:17:52 -0400 (EDT) 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 A589644379 for ; Thu, 18 May 2000 15:17:49 -0400 (EDT) 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 PAA03380; Thu, 18 May 2000 15:25:12 -0400 (EDT) Message-ID: <39244398.7CD5A86D@cs.columbia.edu> Date: Thu, 18 May 2000 15:25:12 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Francois-Xavier Guitton Cc: SIP Subject: Re: [SIP] Use of warning header in an INVITE message References: <391BD365.1ADCE8E9@ms.alcatel.fr> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Francois-Xavier Guitton wrote: > > Hello, > > RFC 2543 specifies warning header as optional in the INVITE method. > But the chapter describing Warning (6.41 Warning p 72) only details > the usage of that header in case of a response. So my question is: > what is the purpose of the warning header in an INVITE message ? > This simply means it is optinal in a Warning header returned in response to any request. Cf., for example, the description of the Contact header. > > -- 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 May 18 15:29:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12187 for ; Thu, 18 May 2000 15:29:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 22C38443B6; Thu, 18 May 2000 15:21:39 -0400 (EDT) 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 35B97443C3 for ; Thu, 18 May 2000 15:21:36 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA12379; Thu, 18 May 2000 12:29:10 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26200; Thu, 18 May 2000 12:29:02 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14628.17534.120289.333326@thomasm-u1.cisco.com> Date: Thu, 18 May 2000 12:29:02 -0700 (PDT) To: Giuseppe Ricagni Cc: Michael Thomas , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <39243B1F.E6ED1678@italtel.it> References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> <39238524.A3263087@dynamicsoft.com> <3923E6CA.941FA323@italtel.it> <14628.8344.56504.279408@thomasm-u1.cisco.com> <39243B1F.E6ED1678@italtel.it> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Giuseppe Ricagni writes: > * When the callee is roaming, either you use a standardized database transport protocol or you > delegate the callee home domain proxy to perform the query, but you have a RTT towards the callee > home domain. Which may effectively be zero. > Your solution of having synchronized copies of such database all over the world is > another interesting enhancement, maybe expensive (pretty sure off-the-shelf solutions are already > out there) It doesn't sound much more interesting than a localize LDAP cache on the client proxy. There are other ways to do this as well. And it doesn't imply synchronized; all that is necessary are caches with TTL's. > o the point I was making was that for all subsequent mid-call messages, just like the INVITEs > you have to send for handovers, you should shortcut and avoid the round trip to the home > net. I disagree. Most traffic is between the two UA's. And it absolutely does not follow that proxies need to have any part in handoffs. In fact, I do not believe that proxies have any part in handoffs when the UA is in the mobile unit. > * When the caller is roaming, under certain circumstances (related to the type of value added > services required & the set of services supported by the visited network & the possibility to > transfer a user profile--see my previous messages) I don't know what services the roaming network wants to provide -- other than trying to shoehorn themselves into the call. Even if, there is nothing to prevent me from obtaining those service even if it's routed through my home proxy first. 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 May 18 15:34:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12286 for ; Thu, 18 May 2000 15:34:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF262443CA; Thu, 18 May 2000 15:26:10 -0400 (EDT) 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 4F1B444337 for ; Thu, 18 May 2000 15:26:08 -0400 (EDT) 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 PAA04251; Thu, 18 May 2000 15:33:28 -0400 (EDT) Message-ID: <39244588.E7BF97F5@cs.columbia.edu> Date: Thu, 18 May 2000 15:33:28 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Rick Workman , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] URI's in SIP messages References: <200005081932.OAA06333@b04a45.exu.ericsson.se> <39173AAA.E5B25BC7@americasm01.nt.com> <3919E388.A317ECAC@dynamicsoft.com> <391AB09F.917BD671@americasm01.nt.com> <391AF6C0.6C159A84@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Right; I'm basically saying I believe this grammar to be wrong. URI > should be absoluteURI. Changed to: Request-Line & = & Method SP Request-URI SP SIP-Version CRLF\\ Request-URI & = & SIP-URI $|$ absoluteURI where absoluteURI has been defined in RFC 2396. -- 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 May 18 16:00:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12438 for ; Thu, 18 May 2000 16:00:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6EFE344379; Thu, 18 May 2000 15:52:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 2F98444337 for ; Thu, 18 May 2000 15:52:31 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id VAA29211 for ; Thu, 18 May 2000 21:58:40 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id VAA15635 for ; Thu, 18 May 2000 21:57:22 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id VAA23783 for ; Thu, 18 May 2000 21:57:42 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA4F18; Thu, 18 May 2000 22:07:39 +0200 Message-ID: <39244CBE.FA08B15A@italtel.it> Date: Thu, 18 May 2000 22:04:16 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> <39238524.A3263087@dynamicsoft.com> <3923E6CA.941FA323@italtel.it> <14628.8344.56504.279408@thomasm-u1.cisco.com> <39243B1F.E6ED1678@italtel.it> <14628.17534.120289.333326@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sorry Michael, I really think we are looping: can we take it off-line ? Giuseppe Michael Thomas wrote: > Giuseppe Ricagni writes: > > * When the callee is roaming, either you use a standardized database transport protocol or you > > delegate the callee home domain proxy to perform the query, but you have a RTT towards the callee > > home domain. > > Which may effectively be zero. > > > Your solution of having synchronized copies of such database all over the world is > > another interesting enhancement, maybe expensive (pretty sure off-the-shelf solutions are already > > out there) > > It doesn't sound much more interesting than a > localize LDAP cache on the client proxy. There > are other ways to do this as well. And it doesn't > imply synchronized; all that is necessary are caches > with TTL's. > > > o the point I was making was that for all subsequent mid-call messages, just like the INVITEs > > you have to send for handovers, you should shortcut and avoid the round trip to the home > > net. > > I disagree. Most traffic is between the two UA's. > And it absolutely does not follow that proxies > need to have any part in handoffs. In fact, I > do not believe that proxies have any part in > handoffs when the UA is in the mobile unit. > > > * When the caller is roaming, under certain circumstances (related to the type of value added > > services required & the set of services supported by the visited network & the possibility to > > transfer a user profile--see my previous messages) > > I don't know what services the roaming network > wants to provide -- other than trying to shoehorn > themselves into the call. Even if, there is nothing > to prevent me from obtaining those service even if > it's routed through my home proxy first. > > Mike -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 16:50:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13016 for ; Thu, 18 May 2000 16:50:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0616844396; Thu, 18 May 2000 16:42:58 -0400 (EDT) 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 5B1E744337 for ; Thu, 18 May 2000 16:42:56 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Thu, 18 May 2000 15:25:53 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LF48MTCA; Thu, 18 May 2000 16:25:30 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LCMSPB1N; Thu, 18 May 2000 16:25:30 -0400 Message-ID: <39245260.F9F45E29@americasm01.nt.com> Date: Thu, 18 May 2000 16:28:16 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Jonathan Rosenberg , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] URI's in SIP messages References: <200005081932.OAA06333@b04a45.exu.ericsson.se> <39173AAA.E5B25BC7@americasm01.nt.com> <3919E388.A317ECAC@dynamicsoft.com> <391AB09F.917BD671@americasm01.nt.com> <391AF6C0.6C159A84@dynamicsoft.com> <39244588.E7BF97F5@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------E6ECBFE69F1E93845CBD7A3A" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------E6ECBFE69F1E93845CBD7A3A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Henning, I assume this also applies to "addr-spec" in [6.15]. Also SIP-URI currently called SIP-URL [2]; doesn't matter as long as it's consistant. Rick Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > > > > > Right; I'm basically saying I believe this grammar to be wrong. URI > > should be absoluteURI. > > Changed to: > > Request-Line & = & Method SP Request-URI SP SIP-Version CRLF\\ > Request-URI & = & SIP-URI $|$ absoluteURI > > where absoluteURI has been defined in RFC 2396. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------------E6ECBFE69F1E93845CBD7A3A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Henning,

I assume this also applies to "addr-spec" in [6.15]. Also SIP-URI currently called SIP-URL [2]; doesn't matter as long as it's consistant.

Rick

Henning Schulzrinne wrote:

Jonathan Rosenberg wrote:
>
>
> Right; I'm basically saying I believe this grammar to be wrong. URI
> should be absoluteURI.

Changed to:

Request-Line & = & Method SP Request-URI SP SIP-Version CRLF\\
Request-URI  & = & SIP-URI $|$ absoluteURI

where absoluteURI has been defined in RFC 2396.

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

--------------E6ECBFE69F1E93845CBD7A3A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 17:04:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13155 for ; Thu, 18 May 2000 17:04:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0102A443D4; Thu, 18 May 2000 16:56:57 -0400 (EDT) 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 417E3443CC for ; Thu, 18 May 2000 16:56:55 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA18095; Thu, 18 May 2000 14:04:25 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA26214; Thu, 18 May 2000 14:04:17 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14628.23249.685868.252594@thomasm-u1.cisco.com> Date: Thu, 18 May 2000 14:04:17 -0700 (PDT) To: Henning Schulzrinne Cc: Giuseppe Ricagni , Jonathan Rosenberg , Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <3922962C.E9B5433C@cs.columbia.edu> References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <3922962C.E9B5433C@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/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > There seem to be two cases: > > 1) The callee is local and the caller is roaming. In that case, there's > no reason to have the caller go through its remote (home) proxy for > sending SIP requests (except if that home proxy performs, for example, > authentication services). That's a pretty big exception. I think there's a lot more reasons, like for example there is no standard way of the roamed proxy to know what my subscriber information is. Nor should there be any expectation that a roamed proxy would know what to do with that information except for a the barest least common denominator. > 2) The callee is roaming (independent of where the caller is). The SIP > call has no choice but to go the home proxy of the callee first, since > that's the only reference point for the caller. It has no clue that the > callee is standing right next to him/her. This no different than the non-roamed case. 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 May 18 17:31:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13393 for ; Thu, 18 May 2000 17:31:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E83D443DF; Thu, 18 May 2000 17:24:08 -0400 (EDT) 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 4C5D844337 for ; Thu, 18 May 2000 17:24:03 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA08137; Thu, 18 May 2000 14:31:37 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA26220; Thu, 18 May 2000 14:31:30 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14628.24882.15278.231237@thomasm-u1.cisco.com> Date: Thu, 18 May 2000 14:31:30 -0700 (PDT) To: "Dean Willis" Cc: "IETF SIP" , "Michael Thomas" Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) In-Reply-To: <003201bfc04d$7cdf7fa0$56fa403f@directlink.net> References: <14626.54617.648412.299580@thomasm-u1.cisco.com> <003201bfc04d$7cdf7fa0$56fa403f@directlink.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dean Willis writes: > Consider it in an aggregation model, like a donut. The chewy outside parts of the donut are controlled by IntServ. Traffic leaps across the DiffServ donut-hole only if the heuristic process thinks (IE, is reasonably sure) that there is adequate bandwidth. OK, but I still don't see what that has to do with proxies. That sounds like something an edge router would do before it admits diffserv traffic into the diffserv core. Proxies are even more clueless because they never see the actual traffic patterns. 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 May 18 18:46:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13934 for ; Thu, 18 May 2000 18:46:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44C374437F; Thu, 18 May 2000 18:38:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 8241F44337 for ; Thu, 18 May 2000 18:38:31 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA11948 for ; Thu, 18 May 2000 17:47:51 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA29955 for ; Thu, 18 May 2000 17:45:27 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Thu, 18 May 2000 17:45:27 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790C9@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: sip@lists.bell-labs.com Date: Thu, 18 May 2000 17:45:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] draft-singh-sip-h323-01.txt comments Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 5.1.3, considering the case where the IWF does not contain a registrar or a gatekeeper, says "If the destination address does not indicate the signaling protocol, a SIP proxy server has to forward all incoming requests to a local IWF, just in case the destination happens to be reachable via H.323." Is this strictly true? It would seem to me that a SIP proxy would first try to find the called party using its normal SIP mechanisms, which would work as usual for most cases (SIP-to-SIP, non-interworked calls). Only if the SIP proxy could not find the called party would it forward the call to an H.323 IWF, hoping to find the destination in the H.323 cloud before returning a 404 Not Found response. 4, requirement #2, says "the user may dial any address without actually knowing whether it belongs to the H.323 or the SIP cloud" Is 'dial' referring to a SIP request to a tel URL? Or just a request with a more general destination (perhaps an alias) than a sip URL? Tim Schroeder SBC Technology Resources _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 18 18:57:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14064 for ; Thu, 18 May 2000 18:57:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4CC9D443BC; Thu, 18 May 2000 18:49:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lists.bell-labs.com (Postfix) with ESMTP id A2928443BA for ; Thu, 18 May 2000 18:49:46 -0400 (EDT) Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Thu, 18 May 2000 11:38:41 -0400 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LCNYARGV; Thu, 18 May 2000 08:38:34 -0700 Received: from long-pc.corpwest.baynetworks.com. (LONG-PC [134.177.35.33]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJLBY7VM; Thu, 18 May 2000 08:38:06 -0700 Message-Id: <3.0.1.32.20000518083819.01345aac@zsc4c006.corpwest.baynetworks.com> X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 18 May 2000 08:38:19 -0700 To: Kevin Summers , sip@lists.bell-labs.com X-Sybari-Space: 00000000 00000000 00000000 From: "Lyndon Ong" Subject: Re: [SIP] Payload Boundary of ISUP Object? In-Reply-To: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Kevin, Actually it mentions this in the Example, we could simply move this up to Section 3.1 instead. Cheers, L. Ong At 10:26 AM 5/18/2000 -0500, Kevin Summers wrote: >In draft-ietf-sip-isup-mime-01.txt, it is not explicitly stated where >encapsulation of an ISUP message should begin. It seems logical to begin >with the message type (as the example in the draft shows), but nowhere does >the draft prescribe exactly where to start. > >I don't think that this decision should to be left to the implementors -- >perhaps we should strengthen the requirements of how the message is >encapsulated. >Any thoughts? > >Kevin Summers > > >message scanned for virus content. > >telecom technologies, inc. >http://www.ttiweb.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 May 18 19:46:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14693 for ; Thu, 18 May 2000 19:46:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C81E443A4; Thu, 18 May 2000 19:39:08 -0400 (EDT) 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 F30FC44337 for ; Thu, 18 May 2000 19:39:05 -0400 (EDT) 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 TAA24434 for ; Thu, 18 May 2000 19:46:34 -0400 (EDT) Message-ID: <392480DA.68A0120C@cs.columbia.edu> Date: Thu, 18 May 2000 19:46:34 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [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] New 2543bis draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Still only in PostScript; see http://www.cs.columbia.edu/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 Fri May 19 01:03:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19139 for ; Fri, 19 May 2000 01:03:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E63B8443A8; Fri, 19 May 2000 00:56:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id 0829544337 for ; Fri, 19 May 2000 00:51:32 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA01467 for ; Fri, 19 May 2000 11:11:20 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568E4.001C1F87 ; Fri, 19 May 2000 10:37:10 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <652568E4.001C1EAC.00@sampark.hss.hns.com> Date: Fri, 19 May 2000 10:37:08 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Question abt. Content-Disposition Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, According to the description of Content-Dispotion (C-D) header, its role is to tell the UA whether the message (part) has to be necessarily idenfied or not by the UA. So, if I had a MIME header with 2 parts, with my first part being an ISUP encoded payload and my second part being a message which I really dont care if the UA understands or not, I do: --- begin ---- INVITE sip:01628434456@dcs1.nortelnetworks.com SIP/2.0 Content-Type: multipart/mixed; boundary=unique-boundary-1 --unique-boundary-1 Content-type:application/isup Content-Transfer-Encoding: binary .. ... --unique-boundary-1 Content-type:application/moohaa Content-Diposition:inline;handling=optional I dont really care if you understand me or not --unique-boundary-1-- --- end --- Is the above correct ? I could find any reference to what the disposition type token is all abt, and when I should specify which. Also, what is the extension-param in disposition type for ? If all its use is to tell the UA to mandatorily/optionally understand a message part, then isnt Content-Disposition - "Content-Disposition" ":" dispositon-type disposition-type = "optional" | "required" enough ? 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 Fri May 19 02:54:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01221 for ; Fri, 19 May 2000 02:54:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 612BE443AF; Fri, 19 May 2000 02:47:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 42BA344337 for ; Fri, 19 May 2000 02:47:06 -0400 (EDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4J6rvO13462 for ; Fri, 19 May 2000 08:53:58 +0200 (MET DST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FUS00A01OHXFW@mbb1.ericsson.se> for sip@lists.bell-labs.com; Fri, 19 May 2000 08:53:57 +0200 (MET DST) Received: from era.ericsson.se (kipe137.eraj.ericsson.se [147.214.68.137]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FUS008FJOHWHK@mbb1.ericsson.se>; Fri, 19 May 2000 08:53:57 +0200 (MET DST) Date: Fri, 19 May 2000 08:53:12 +0200 From: Stephen Terrill Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide To: Ashutosh Dutta Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Message-id: <3924E4D8.6D9B92E6@era.ericsson.se> Organization: L.M. Ericsson MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win98; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <852568E1.00456034.00@notes949.cc.telcordia.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8BIT Hi All, This is under the assumption that as a user moves during a conversation, the point of presence to the IP also moves. In the popular radio access systems that I am aware of, this doesn´t happen, the "mico-mobility" (as it is sometimes refered to) is taken care of by the packer radio access network. Regards, ..//Steve Ashutosh Dutta wrote: > As far as whether to talk to the home proxy or local proxy, for a wireless > roaming user which is changing domains frequently during mid-session-call and > is on the move, it may be better to talk to the local proxy rather than going to > the home proxy all the way during every hand-off (for latency reason I guess), > of course there needs to be a security association between the local-proxy and > home proxy or via public-proxy. This is one of the things we were trying to > debate during SIP-2000 conference in Paris last week to see the trade-off > between either talking to home-proxy or local domain proxy during frequent > hand-off, then there is also a possibility of interaction between local SIP > server and AAA server for a roaming user's profile verification during domain > handoff. > > Thanks > Ashutosh > > _______________________________________________ > 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 May 19 03:50:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01460 for ; Fri, 19 May 2000 03:50:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD6F8443BA; Fri, 19 May 2000 03:42:53 -0400 (EDT) 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 DF56744337 for ; Fri, 19 May 2000 03:42:50 -0400 (EDT) Received: by SPEED01 with Internet Mail Service (5.5.2650.21) id ; Fri, 19 May 2000 09:46:28 +0200 Message-ID: <2160ABC55998D311821900508B2C14BB269D54@SPEED01> From: =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= To: "'Giuseppe Ricagni '" , "'Michael Thomas '" Cc: "'sip@lists.bell-labs.com '" Date: Fri, 19 May 2000 09:46:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Forcing call setup through home proxy (solution?) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01460 As I said before, some services to set up a call might depend on information that only is available in the callers home network, and for security or policy reasons might be impossible to access from other networks. In this case MUST the call setup signaling go through the home network. I belive that this could be solved by adding a route header field containing the address of the home server in the Invite message. If you follow the spec must the first proxy in the visited network route the Invite to the home proxy. This method allows for optimizing call setup when there is no service that requires routing through the home network, and a method to indicate when so should be the case. /Jörgen >* When the caller is roaming, under certain circumstances (related >to the type of value added services required & the set of services >supported by the visited network & the possibility to transfer a user >profile--see my previous messages) it is possible to avoid sending >signalling back to the caller home domain. This applies to calls towards >the fixed network (which may be routed by TRIP) and for calls to local >mobiles. For roaming mobiles you fall back to the prvious case: still >you don' t need to send signalling to the caller home domain, but you >have a RTT to the callee home domain. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 05:43:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02136 for ; Fri, 19 May 2000 05:43:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78DD644344; Fri, 19 May 2000 05:36:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mex.italtel.it (mex.italtel.it [138.132.117.4]) by lists.bell-labs.com (Postfix) with ESMTP id 00BC944337 for ; Fri, 19 May 2000 05:36:12 -0400 (EDT) Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id LAA01383 for ; Fri, 19 May 2000 11:42:24 +0200 (MET DST) Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP id LAA19401 for ; Fri, 19 May 2000 11:41:03 +0200 (MET DST) Received: from ic8ss11.settimo.italtel.it (ic8ss11.settimo.italtel.it [138.132.57.74]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id LAA24524 for ; Fri, 19 May 2000 11:41:23 +0200 (MET DST) Received: from italtel.it ([138.132.59.38]) by ic8ss11.settimo.italtel.it (Netscape Messaging Server 3.5) with ESMTP id AAA6BFC; Fri, 19 May 2000 11:51:20 +0200 Message-ID: <39250DCC.6117FD3D@italtel.it> Date: Fri, 19 May 2000 11:47:56 +0200 From: Giuseppe Ricagni X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Terrill Cc: Ashutosh Dutta , Michael Thomas , James Kempf , sip@lists.bell-labs.com, jdrosen@dynamicsoft.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <852568E1.00456034.00@notes949.cc.telcordia.com> <3924E4D8.6D9B92E6@era.ericsson.se> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hello Stephen, Stephen Terrill wrote: > Hi All, > > This is under the assumption that as a user moves during a conversation, the point of presence to the IP also moves. In the popular radio access systems that I am aware of, this doesn´t happen, the "mico-mobility" (as it is sometimes refered to) is taken care of by the packer radio access network. > As you will know, that is only *part* of the picture.... Cheers Giuseppe > > Regards, > > ..//Steve > > Ashutosh Dutta wrote: > > > As far as whether to talk to the home proxy or local proxy, for a wireless > > roaming user which is changing domains frequently during mid-session-call and > > is on the move, it may be better to talk to the local proxy rather than going to > > the home proxy all the way during every hand-off (for latency reason I guess), > > of course there needs to be a security association between the local-proxy and > > home proxy or via public-proxy. This is one of the things we were trying to > > debate during SIP-2000 conference in Paris last week to see the trade-off > > between either talking to home-proxy or local domain proxy during frequent > > hand-off, then there is also a possibility of interaction between local SIP > > server and AAA server for a roaming user's profile verification during domain > > handoff. > > > > Thanks > > Ashutosh > > > > _______________________________________________ > > 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 -- ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 06:22:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02330 for ; Fri, 19 May 2000 06:22:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 909F044337; Fri, 19 May 2000 06:14:49 -0400 (EDT) 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 EF3E1443CC for ; Fri, 19 May 2000 06:14:45 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id FAA08863; Fri, 19 May 2000 05:21:54 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id FAA21827; Fri, 19 May 2000 05:21:51 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id FAA16155; Fri, 19 May 2000 05:21:50 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id FAA08278; Fri, 19 May 2000 05:21:49 -0500 (CDT) Message-Id: <200005191021.FAA08278@b04a24.exu.ericsson.se> Subject: Re: [SIP] Problem with definition of In-Reply-To grammar To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Fri, 19 May 2000 05:21:49 -0500 (CDT) Cc: schulzrinne@cs.columbia.edu (Henning Schulzrinne), gethin@ubiquity.net (Gethin Liddell), sip@lists.bell-labs.com (Sip Mail List) In-Reply-To: <39238002.E53C2169@dynamicsoft.com> from "Jonathan Rosenberg" at May 18, 2000 01:30:42 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >> Indeed, earlier we had agreed to use 'token' | 'token' @ 'token' or >> something like that as the appropriate BNF entity. > >I agree completely. There is no reason to make life more complicated >here. To keep overaggressive parsers from choking on e.g. 1234@192.168.1.20@domain.com, I'd propose: token *( "@" token ) ...with a RECOMMENDATION that they be of the format currently described in 2543. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 06:49:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02458 for ; Fri, 19 May 2000 06:49:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A7F8443C3; Fri, 19 May 2000 06:41:37 -0400 (EDT) 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 8CB72443C1 for ; Fri, 19 May 2000 06:41:34 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id FAA12916; Fri, 19 May 2000 05:49:07 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id FAA00674; Fri, 19 May 2000 05:49:04 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id FAA16963; Fri, 19 May 2000 05:49:03 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id FAA08370; Fri, 19 May 2000 05:49:03 -0500 (CDT) Message-Id: <200005191049.FAA08370@b04a24.exu.ericsson.se> Subject: Re: [SIP] Forcing call setup through home proxy (solution?) To: Jorgen.Bjorkner@hotsip.com (=?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?=) Date: Fri, 19 May 2000 05:49:02 -0500 (CDT) Cc: giuseppe.ricagni@italtel.it ('Giuseppe Ricagni '), mat@cisco.com ('Michael Thomas '), sip@lists.bell-labs.com ('sip@lists.bell-labs.com ') In-Reply-To: <2160ABC55998D311821900508B2C14BB269D54@SPEED01> from "=?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?=" at May 19, 2000 09:46:17 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >As I said before, some services to set up a call might depend on = >information >that only is available in the callers home network, and for security or >policy reasons might be impossible to access from other networks. In = >this >case MUST the call setup signaling go through the home network. > >I belive that this could be solved by adding a route header field = >containing >the address of the home server in the Invite message. If you follow the = >spec >must the first proxy in the visited network route the Invite to the = >home >proxy. This method allows for optimizing call setup when there is no = >service >that requires routing through the home network, and a method to = >indicate >when so should be the case. At the third bakeoff, I went around to a number of people and asked how their proxies would behave if my client did this sort of thing. I got a variety of mixed answers, none of which were very encouraging. Some people wouldn't process it, for example, unless it had a To: tag (since routes can't appear on leg setup messages, or so goes the thinking). Most would completely forgo their internal logic and blindly forward the message (thus making their purpose only to add to the number of hops in the call signalling route). I've been mulling this problem since. I don't think there's really a good solution; however, I want to run something by the group. Back in the day, you could manually route e-mail messages through a variety of servers by specifying an email address of the format adam.roach%internal_host@ericsson.com. Upon receiving this, ericsson.com would turn the last % into an @ and continue routing the message. This could be indefinitely chained to produce something like adam.roach%host3%host2%host1@ericsson.com which would route the message through ericsson.com, then host1, then host2, and finally deliver it to host3. So, what if we specified a fairly simple username convention stating that proxies MAY do something similar; for example, you could send something like: INVITE sip:jorgen.bjorkner%40ericsson.com@firewall.mycompany.com SIP/2.0 ...to the machine "localservices.mycompany.com". When the machine "firewall.mycompany.com" received the message, based on the presence of an escaped @ sign in the user field, he would strip the machine name in the request URI, expand the rightmost escaped @, and use that for his new request URI: INVITE sip:jorgen.bjorkner@ericsson.com SIP/2.0 Questions? Comments? Is there enough interest in this to warrant putting together a formal document? -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 09:13:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04678 for ; Fri, 19 May 2000 09:13:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3EF1443C8; Fri, 19 May 2000 09:05:19 -0400 (EDT) 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 202B94435B for ; Fri, 19 May 2000 09:05:15 -0400 (EDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Fri, 19 May 2000 08:11:27 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 May 2000 08:11:06 -0500 Message-ID: From: "Glenn Morrow" To: "'Adam B. Roach'" , Jorgen.Bjorkner@hotsip.com Cc: giuseppe.ricagni@italtel.it, mat@cisco.com, sip@lists.bell-labs.com Subject: RE: [SIP] Forcing call setup through home proxy (solution?) Date: Fri, 19 May 2000 08:11:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC193.B09C0452" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFC193.B09C0452 Content-Type: text/plain; charset="ISO-8859-1" Can't the Request-URI be used to achieve this functionality? UA Oriented: I.e. the SIP message's IP destination could be the serving proxy in the visited network and the Request-URI could indicate the home proxy. This would allow the UA to be in control over whether the home proxy was in the loop. See section 6.33.4 in http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf. [ Page 51 ] Script or Network Oriented: An network oriented alternative would be to have scripts, profile or triggers loaded on the serving proxy to rewrite or include the Request-URI indicating involvement of the home server. This may or may not run into the "gag me with a spoon" issue that Mike alluded to depending on where the script came from. Really Crapy Solution: Yet another network oriented method would be to simply have the service logic on the serving proxy simply proxy the message to the address of the home proxy; however, this would only work if no other proxies are needed to be in the loop between the serving and home proxies- don't recommend. This last one is a bad solution that I personally believe violates the principles of SIP. It's a hack. I believe all of these methods except the last would allow a per-message selection of home proxy involvement, be legal in SIP and not go against the design principles of the architecture. Are there any issues with the SIP violations that anyone is aware of for the first two methods above? > -----Original Message----- > From: Adam B. Roach [SMTP:Adam.Roach@Ericsson.com] > Sent: Friday, May 19, 2000 5:49 AM > To: Jorgen.Bjorkner@hotsip.com > Cc: giuseppe.ricagni@italtel.it; mat@cisco.com; sip@lists.bell-labs.com > Subject: Re: [SIP] Forcing call setup through home proxy (solution?) > > >As I said before, some services to set up a call might depend on = > >information > >that only is available in the callers home network, and for security or > >policy reasons might be impossible to access from other networks. In = > >this > >case MUST the call setup signaling go through the home network. > > > >I belive that this could be solved by adding a route header field = > >containing > >the address of the home server in the Invite message. If you follow the = > >spec > >must the first proxy in the visited network route the Invite to the = > >home > >proxy. This method allows for optimizing call setup when there is no = > >service > >that requires routing through the home network, and a method to = > >indicate > >when so should be the case. > > At the third bakeoff, I went around to a number of people and > asked how their proxies would behave if my client did this sort of > thing. I got a variety of mixed answers, none of which were > very encouraging. Some people wouldn't process it, for example, > unless it had a To: tag (since routes can't appear on leg > setup messages, or so goes the thinking). Most would completely > forgo their internal logic and blindly forward the message > (thus making their purpose only to add to the number of hops > in the call signalling route). > > I've been mulling this problem since. I don't think there's > really a good solution; however, I want to run something by > the group. > > Back in the day, you could manually route e-mail messages through > a variety of servers by specifying an email address of the format > adam.roach%internal_host@ericsson.com. Upon receiving this, > ericsson.com would turn the last % into an @ and continue > routing the message. This could be indefinitely chained > to produce something like adam.roach%host3%host2%host1@ericsson.com > which would route the message through ericsson.com, then host1, > then host2, and finally deliver it to host3. > > So, what if we specified a fairly simple username convention > stating that proxies MAY do something similar; for example, > you could send something like: > > INVITE sip:jorgen.bjorkner%40ericsson.com@firewall.mycompany.com SIP/2.0 > > ...to the machine "localservices.mycompany.com". When the > machine "firewall.mycompany.com" received the message, based on > the presence of an escaped @ sign in the user field, he would > strip the machine name in the request URI, expand the rightmost > escaped @, and use that for his new request URI: > > INVITE sip:jorgen.bjorkner@ericsson.com SIP/2.0 > > Questions? Comments? Is there enough interest in this to > warrant putting together a formal document? > > -- > Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS > L-04 > adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 > USA > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFC193.B09C0452 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Forcing call setup through home proxy = (solution?)

Can't the = Request-URI be used to achieve this functionality?

UA Oriented:

Script or Network = Oriented:

    An network oriented = alternative would be to have scripts, profile or triggers loaded on the = serving proxy to rewrite or include the Request-URI indicating = involvement of the home server. This may or may not run into the = "gag me with a spoon" issue that Mike alluded to depending on = where the script came from.

Really Crapy = Solution:

    Yet another network = oriented method would be to simply have the service logic on the = serving proxy simply proxy the message to the address of the home = proxy; however, this would only work if no other proxies are needed to = be in the loop between the serving and home proxies- don't recommend. = This last one is a bad solution that I personally believe violates the = principles of SIP. It's a hack.

I believe all of = these methods except the last would allow a per-message selection of = home proxy involvement, be legal in SIP and not go against the design = principles of the architecture.

Are there any issues = with the SIP violations that anyone is aware of for the first two = methods above?



    -----Original Message-----
    From:   Adam B. Roach = [SMTP:Adam.Roach@Ericsson.com]
    Sent:   Friday, May 19, 2000 5:49 AM
    To:     Jorgen.Bjorkner@hotsip.com
    Cc:     giuseppe.ricagni@italtel.it; mat@cisco.com; = sip@lists.bell-labs.com
    Subject:       = Re: [SIP] Forcing call setup through = home proxy (solution?)

    >As I said before, some services to = set up a call might depend on =3D
    >information
    >that only is available in the = callers home network, and for security or
    >policy reasons might be = impossible to access from other networks. In =3D
    >this
    >case MUST the call setup = signaling go through the home network.
    >
    >I belive that this could be = solved by adding a route header field =3D
    >containing
    >the address of the home server in = the Invite message. If you follow the =3D
    >spec
    >must the first proxy in the = visited network route the Invite to the =3D
    >home
    >proxy. This method allows for = optimizing call setup when there is no =3D
    >service
    >that requires routing through the = home network, and a method to =3D
    >indicate
    >when so should be the = case.

    At the third bakeoff, I went around to = a number of people and
    asked how their proxies would behave = if my client did this sort of
    thing. I got a variety of mixed = answers, none of which were
    very encouraging. Some people = wouldn't process it, for example,
    unless it had a To: tag (since routes = can't appear on leg
    setup messages, or so goes the = thinking). Most would completely
    forgo their internal logic and = blindly forward the message
    (thus making their purpose only to = add to the number of hops
    in the call signalling route).

    I've been mulling this problem since. = I don't think there's
    really a good solution; however, I = want to run something by
    the group.

    Back in the day, you could manually = route e-mail messages through
    a variety of servers by specifying an = email address of the format
    adam.roach%internal_host@ericsson.com. Upon receiving = this,
    ericsson.com would turn the last % = into an @ and continue
    routing the message. This could be = indefinitely chained
    to produce something like = adam.roach%host3%host2%host1@ericsson.com
    which would route the message through = ericsson.com, then host1,
    then host2, and finally deliver it to = host3.

    So, what if we specified a fairly = simple username convention
    stating that proxies MAY do something = similar; for example,
    you could send something like:

    INVITE = sip:jorgen.bjorkner%40ericsson.com@firewall.mycompany.com = SIP/2.0

    ...to the machine = "localservices.mycompany.com". When the
    machine = "firewall.mycompany.com" received the message, based = on
    the presence of an escaped @ sign in = the user field, he would
    strip the machine name in the request = URI, expand the rightmost
    escaped @, and use that for his new = request URI:

    INVITE = sip:jorgen.bjorkner@ericsson.com SIP/2.0

    Questions? Comments? Is there enough = interest in this to
    warrant putting together a formal = document?

    --
    Adam Roach, Ericsson Inc. |  Ph: = +1 972 583 7594 | 1010 E. Arapaho, MS L-04
    adam.roach@ericsson.com   | = Fax: +1 972 669 0154 | Richardson, TX 75081 USA


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

------_=_NextPart_001_01BFC193.B09C0452-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 09:38:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05051 for ; Fri, 19 May 2000 09:38:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8593244374; Fri, 19 May 2000 09:30:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhost.ttimail.com (mailhost.ttimail.com [209.136.128.4]) by lists.bell-labs.com (Postfix) with SMTP id 211704435B for ; Fri, 19 May 2000 09:30:27 -0400 (EDT) Received: From MAILHOST.TTIMAIL.COM (10.10.100.5[10.10.100.5 port:4860]) by mailhost.ttimail.com Mail essentials (server 2.422) with SMTP id: <989@mailhost.ttimail.com> for ; Fri, 19 May 2000 8:37:24 AM -0500 smtpmailfrom Received: by mailhost.tti.net with Internet Mail Service (5.5.2650.21) id ; Fri, 19 May 2000 08:37:24 -0500 Message-ID: From: Kevin Summers To: "'Lyndon Ong'" , Kevin Summers , sip@lists.bell-labs.com Subject: RE: [SIP] Payload Boundary of ISUP Object? Date: Fri, 19 May 2000 08:37:24 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Yes, I think moving it and clearly stating that it is expected that message type is where encapsulation starts would be ideal. -----Original Message----- From: Lyndon Ong [mailto:long@nortelnetworks.com] Sent: Thursday, May 18, 2000 10:38 AM To: Kevin Summers; sip@lists.bell-labs.com Subject: Re: [SIP] Payload Boundary of ISUP Object? Kevin, Actually it mentions this in the Example, we could simply move this up to Section 3.1 instead. Cheers, L. Ong At 10:26 AM 5/18/2000 -0500, Kevin Summers wrote: >In draft-ietf-sip-isup-mime-01.txt, it is not explicitly stated where >encapsulation of an ISUP message should begin. It seems logical to begin >with the message type (as the example in the draft shows), but nowhere does >the draft prescribe exactly where to start. > >I don't think that this decision should to be left to the implementors -- >perhaps we should strengthen the requirements of how the message is >encapsulated. >Any thoughts? > >Kevin Summers > > >message scanned for virus content. > >telecom technologies, inc. >http://www.ttiweb.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 message scanned for virus content. telecom technologies, inc. http://www.ttiweb.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 May 19 11:59:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07387 for ; Fri, 19 May 2000 11:59:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0CA9B443C4; Fri, 19 May 2000 11:51:31 -0400 (EDT) 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 2D472443C1 for ; Fri, 19 May 2000 11:51:28 -0400 (EDT) To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: From: Ganesh.Ramamoorthy@jax.ecitele.com Date: Fri, 19 May 2000 11:57:28 -0400 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on USMLNS02/JAX/ECI Telecom(Release 5.0.1a|August 17, 1999) at 05/19/2000 11:57:29 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] SIP and SCTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Just joined this list! Has there been a discussion in this list about using SCTP as the transport for SIP? I would appreciate it if someone could share their ideas on this topic. Thanks in advance. Ganesh Ramamoorthy _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 13:00:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08293 for ; Fri, 19 May 2000 13:00:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E92A6443C3; Fri, 19 May 2000 12:53:06 -0400 (EDT) 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 751CD443C1 for ; Fri, 19 May 2000 12:53:03 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id MAA02829 for ; Fri, 19 May 2000 12:00:35 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id MAA28302 for ; Fri, 19 May 2000 12:00:32 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA04864 for ; Fri, 19 May 2000 12:00:31 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id MAA21271 for sip@lists.bell-labs.com; Fri, 19 May 2000 12:00:30 -0500 (CDT) Date: Fri, 19 May 2000 12:00:30 -0500 (CDT) Message-Id: <200005191700.MAA21271@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com X-Sun-Charset: US-ASCII Subject: [SIP] Clarification of 302 handling Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I thought this was pretty cut and dry, but I noticed some odd behaviour in a SIP client today and after looking through the RFC2543bis draft, I didn't see this spelled out anywhere. Is it legal to rewrite the To: field in a subsequent request that resulted from a 302 response? (Can you replace the To: field with the Contact: information from the 302 response?) In section 7.3.3 (302 Moved Temporarily), it states "The requesting client SHOULD retry the request at the new address(es) given by the Contact: header field." I interpret this to mean take the same request (To/From/etc. unchanged), replace the Request-URI with the Contact: in the 302, and re-issue the request to the new address specified in the Request-URI. I can understand changing the From: perhaps, but changing the To: seems a bit odd. If you can't count on the To: header being immutable to an extent, it makes service creation a little more difficult. Comments? Sean -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 13:03:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08379 for ; Fri, 19 May 2000 13:03:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F25D3443DB; Fri, 19 May 2000 12:54:57 -0400 (EDT) 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 09A7A443D9 for ; Fri, 19 May 2000 12:54:55 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id MAA03658; Fri, 19 May 2000 12:02:31 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id MAA15441; Fri, 19 May 2000 12:02:28 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA04972; Fri, 19 May 2000 12:02:27 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id MAA21274; Fri, 19 May 2000 12:02:26 -0500 (CDT) Date: Fri, 19 May 2000 12:02:26 -0500 (CDT) Message-Id: <200005191702.MAA21274@b04a45.exu.ericsson.se> To: Adam.Roach@Ericsson.com, Jorgen.Bjorkner@hotsip.com, gmorrow@nortelnetworks.com Subject: RE: [SIP] Forcing call setup through home proxy (solution?) Cc: giuseppe.ricagni@italtel.it, mat@cisco.com, sip@lists.bell-labs.com X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Can't the Request-URI be used to achieve this functionality? > Yes, for a single hop. If you want to route your messsage through multiple hops, you can either do what Adam suggested or use Route: headers in the INVITE message. I prefer the later because it would require the least number of changes to existing proxies. > Script or Network Oriented: > > An network oriented alternative would be to have scripts, profile or > triggers loaded on the serving proxy to rewrite or include the Request-URI > indicating involvement of the home server. This may or may not run into the > "gag me with a spoon" issue that Mike alluded to depending on where the > script came from. This is really horrible, mostly because it is overly complex and buys you nothing over the previous solution. Also, the concept of using scripts to control this seems a dangerous road to go down. > > Really Crapy Solution: > > Yet another network oriented method would be to simply have the > service logic on the serving proxy simply proxy the message to the address > of the home proxy; however, this would only work if no other proxies are > needed to be in the loop between the serving and home proxies- don't > recommend. This last one is a bad solution that I personally believe > violates the principles of SIP. It's a hack. > This is even more complex and still buys you nothing over the first solution. The only reason I would imagine involving the network in this case is if you want the network to have some say in how the call setup is routed (which of course you might). If the (roaming) terminal is intelligent enough to detemine that it wants to route through it's home proxy, this is easily done by the terminal. -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 13:52:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08820 for ; Fri, 19 May 2000 13:52:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 591B94435E; Fri, 19 May 2000 13:44:30 -0400 (EDT) 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 AE9DC4434D for ; Fri, 19 May 2000 13:44:27 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 19 13:50:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 30FC044344; Fri, 19 May 2000 13:37:09 -0400 (EDT) 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 0015344341 for ; Fri, 19 May 2000 13:37:08 -0400 (EDT) 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 NAA22650; Fri, 19 May 2000 13:37:06 -0400 (EDT) Message-ID: <39257BC2.BD02F937@cs.columbia.edu> Date: Fri, 19 May 2000 13:37:06 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Igor Slepchin , sip@lists.bell-labs.com Subject: Re: [SIP] New 2543bis draft References: <392480DA.68A0120C@cs.columbia.edu> <3925738F.DD7C02DB@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > Sounds like the new file still have the old date on it: it's dated April > 2000... > Thanks for catching that. If you downloaded the draft and it doesn't say "May 2000", you got the old one. Both PS and PDF versions should now be correct. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 13:54:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08836 for ; Fri, 19 May 2000 13:54:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4C0C4437D; Fri, 19 May 2000 13:46:29 -0400 (EDT) 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 5171244378 for ; Fri, 19 May 2000 13:46:27 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 19 13:52:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 35AAF44345; Fri, 19 May 2000 13:39:19 -0400 (EDT) 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 0D02244341 for ; Fri, 19 May 2000 13:39:19 -0400 (EDT) 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 NAA22744; Fri, 19 May 2000 13:39:19 -0400 (EDT) Message-ID: <39257C47.75917023@cs.columbia.edu> Date: Fri, 19 May 2000 13:39:19 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Clarification of 302 handling References: <200005191700.MAA21271@b04a45.exu.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit There is presumably nothing that can keep a user from cutting-and-pasting the Contact information into a new call To field (particularly if the UA supports ask-me-before-redirection), but that would seem to be unusual behavior. Sean Olson wrote: > > I thought this was pretty cut and dry, but I noticed some odd > behaviour in a SIP client today and after looking through the RFC2543bis > draft, I didn't see this spelled out anywhere. > > Is it legal to rewrite the To: field in a subsequent request that resulted > from a 302 response? (Can you replace the To: field with the Contact: > information from the 302 response?) > > In section 7.3.3 (302 Moved Temporarily), it states > > "The requesting client SHOULD retry the request at the new address(es) > given by the Contact: header field." > > I interpret this to mean take the same request (To/From/etc. unchanged), > replace the Request-URI with the Contact: in the 302, and re-issue > the request to the new address specified in the Request-URI. > > I can understand changing the From: perhaps, but changing the To: seems > a bit odd. If you can't count on the To: header being immutable to an > extent, it makes service creation a little more difficult. > > Comments? > Sean > > -- > Sean Olson > > _______________________________________________ > 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 May 19 14:04:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09009 for ; Fri, 19 May 2000 14:04:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12DBE443C1; Fri, 19 May 2000 13:56:30 -0400 (EDT) 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 92620443AA for ; Fri, 19 May 2000 13:56:27 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 19 14:03:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 78E3B44346; Fri, 19 May 2000 13:45:19 -0400 (EDT) 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 4817844341 for ; Fri, 19 May 2000 13:45:19 -0400 (EDT) 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 NAA22977; Fri, 19 May 2000 13:45:17 -0400 (EDT) Message-ID: <39257DAD.883604B0@cs.columbia.edu> Date: Fri, 19 May 2000 13:45:17 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: "Adam B. Roach" Cc: Jonathan Rosenberg , Gethin Liddell , Sip Mail List Subject: Re: [SIP] Problem with definition of In-Reply-To grammar References: <200005191021.FAA08278@b04a24.exu.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Adam B. Roach wrote: > > >> Indeed, earlier we had agreed to use 'token' | 'token' @ 'token' or > >> something like that as the appropriate BNF entity. > > > >I agree completely. There is no reason to make life more complicated > >here. > > To keep overaggressive parsers from choking on e.g. > 1234@192.168.1.20@domain.com, I'd propose: > > token *( "@" token ) > > ...with a RECOMMENDATION that they be of the format currently described > in 2543. > This wouldn't be backward-compatible. Why encourage such 'strange' formats? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 14:06:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09057 for ; Fri, 19 May 2000 14:06:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB7D2443D9; Fri, 19 May 2000 13:57:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 80C3B443AA for ; Fri, 19 May 2000 13:57:53 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA02384; Fri, 19 May 2000 14:06:31 -0400 (EDT) Message-ID: <39258526.882F0626@dynamicsoft.com> Date: Fri, 19 May 2000 14:17:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Clarification of 302 handling References: <200005191700.MAA21271@b04a45.exu.ericsson.se> <39257C47.75917023@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Right. Any one of several possible behaviors are allowed and will work: 1. The UA basically changes the request URI and uses a different branch ID in the top Via, but the CSeq, To, From and Call-ID are the same. 2. The UA uses a new To field, request URI, but the Call-ID is unchanged (doesn't matter if the CSeq changes, since its defined within the To/From/Call-ID space) 3. The UA uses a brand new To, From, Call-ID, CSeq, etc. as if it were a totally new request. Probably (1) is best, since it will be noted by proxies as being the same request transaction, and thus avoid contacting locations already tried. All three work, but I wouldn't recommend (2), since this might introduce interactions with multiparty conferencing stuff. -Jonathan R. Henning Schulzrinne wrote: > > There is presumably nothing that can keep a user from > cutting-and-pasting the Contact information into a new call To field > (particularly if the UA supports ask-me-before-redirection), but that > would seem to be unusual behavior. > > Sean Olson wrote: > > > > I thought this was pretty cut and dry, but I noticed some odd > > behaviour in a SIP client today and after looking through the RFC2543bis > > draft, I didn't see this spelled out anywhere. > > > > Is it legal to rewrite the To: field in a subsequent request that resulted > > from a 302 response? (Can you replace the To: field with the Contact: > > information from the 302 response?) > > > > In section 7.3.3 (302 Moved Temporarily), it states > > > > "The requesting client SHOULD retry the request at the new address(es) > > given by the Contact: header field." > > > > I interpret this to mean take the same request (To/From/etc. unchanged), > > replace the Request-URI with the Contact: in the 302, and re-issue > > the request to the new address specified in the Request-URI. > > > > I can understand changing the From: perhaps, but changing the To: seems > > a bit odd. If you can't count on the To: header being immutable to an > > extent, it makes service creation a little more difficult. > > > > Comments? > > Sean > > > > -- > > Sean Olson > > > > _______________________________________________ > > 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 -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 14:37:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09328 for ; Fri, 19 May 2000 14:37:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09B7E4434D; Fri, 19 May 2000 14:27:35 -0400 (EDT) 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 6AF8C443D5 for ; Fri, 19 May 2000 14:20:28 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 19 14:26:04 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0C84B44345; Fri, 19 May 2000 14:12:55 -0400 (EDT) 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 DAB5044341 for ; Fri, 19 May 2000 14:12:54 -0400 (EDT) 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 OAA24225; Fri, 19 May 2000 14:12:55 -0400 (EDT) Message-ID: <39258427.FA3783F7@cs.columbia.edu> Date: Fri, 19 May 2000 14:12:55 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Clarification of 302 handling References: <200005191700.MAA21271@b04a45.exu.ericsson.se> <39257C47.75917023@cs.columbia.edu> <39258526.882F0626@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Right. Any one of several possible behaviors are allowed and will work: > > 1. The UA basically changes the request URI and uses a different branch > ID in the top Via, but the CSeq, To, From and Call-ID are the same. > 2. The UA uses a new To field, request URI, but the Call-ID is unchanged > (doesn't matter if the CSeq changes, since its defined within the > To/From/Call-ID space) > 3. The UA uses a brand new To, From, Call-ID, CSeq, etc. as if it were a > totally new request. > > Probably (1) is best, since it will be noted by proxies as being the > same request transaction, and thus avoid contacting locations already > tried. All three work, but I wouldn't recommend (2), since this might > introduce interactions with multiparty conferencing stuff. > Wording added: The new request can take two different forms. In the first approach, the \header{To}, \header{From}, \header{CSeq} and \header{Call-ID} header fields in the new request are the same as in the original request, with a new \header{branch} identifier in the \header{Via} header field. Proxies {\SHOULD} follow this behavior and UACs {\MAY}. UAs {\MAY} also use the \header{Contact} information for the \header{To} header field, as well as a new \header{Call-ID} value. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 14:46:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09400 for ; Fri, 19 May 2000 14:46:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5FC2144361; Fri, 19 May 2000 14:39:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9EC0944357 for ; Fri, 19 May 2000 14:39:08 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA02631; Fri, 19 May 2000 14:48:01 -0400 (EDT) Message-ID: <39258B9C.4D96C8B@dynamicsoft.com> Date: Fri, 19 May 2000 14:44:44 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Henning Schulzrinne Cc: Jonathan Rosenberg , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Clarification of 302 handling References: <200005191700.MAA21271@b04a45.exu.ericsson.se> <39257C47.75917023@cs.columbia.edu> <39258526.882F0626@dynamicsoft.com> <39258427.FA3783F7@cs.columbia.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I believe UAC should increase CSeq if it decides to keep the original To, From and Call-ID in the new request. --- Igor Slepchin Henning Schulzrinne wrote: > Wording added: > > The new request can take two different forms. In the first approach, > the \header{To}, \header{From}, \header{CSeq} and \header{Call-ID} > header fields in the new request are the same as in the original > request, with a new \header{branch} identifier in the \header{Via} > header field. Proxies {\SHOULD} follow this behavior and UACs {\MAY}. > UAs {\MAY} also use the \header{Contact} information for the \header{To} > header field, as well as a new \header{Call-ID} value. > > _______________________________________________ > 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 May 19 15:07:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09583 for ; Fri, 19 May 2000 15:07:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D982F44372; Fri, 19 May 2000 15:00:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1B20E44370 for ; Fri, 19 May 2000 15:00:07 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA02733; Fri, 19 May 2000 15:08:51 -0400 (EDT) Message-ID: <392593C2.8DCA46F2@dynamicsoft.com> Date: Fri, 19 May 2000 15:19:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Giuseppe Ricagni Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> <39238524.A3263087@dynamicsoft.com> <3923E6CA.941FA323@italtel.it> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Giuseppe Ricagni wrote: > > > This presumes that there aren't any other proxies which decide to > > record-route. When a call is made, it will generally pass through > > many > > proxies, each providing differing levels of service. Some of these > > will > > want to record-route.I don't want to prevent them from doing so. > > Basically, the only problem here is that the callee is roaming. > > As Henning reminded us, this requires a database (let' s call it Home > Subscriber Server: HSS, a kind of GSM HLR) lookup by the "calling > proxy" in the callee home domain, to have information about the > address of the proxy the callee is registered at. In SIP, we call that database DNS. > > This lookup can be performed directly by the caller proxy, or via a > callee home domain "home proxy". No - how would we get to the proxy of the callee in the first place without having identified this server? > > This "home proxy" is the only proxy you would like to write in the > record-route and I would like not to. You are missing my point. You are assuming a very specific configuration of two proxies, without any services. In real networks, there will be lots of proxies, many of which are providing a variety of different services. It is the right of these proxies to record-route in order to provide those services. I don't know what those services will be, nor do I know how many proxies there will be. I have heard of trial SIP networks with six proxies on establishment paths. The great thing about SIP is that it allows these kinds of things. So, my point is that GIVEN that there will be other proxies on the path for a variety of reasons, you really won't be able to force signaling to go directly between users, or between users and a local proxy, in most of the cases. > > IMHO, since from a technical point of view you could query the HSS > directly from the calling proxy, you are to involving the "home proxy" > only for "political reasons", to some extent to "filter" queries to > the HSS. No. The home proxy is providing services. > > There is therefore no point in having such proxy in the record-route. I doubt you will be able to dictate to service providers that they are not allowed to provide services in their proxies. > > Also remember we are talking here about basic calls, requesting no > additional services, or services that are user profile independent. > More complex scenarios can be achieved, as I suggested in a previous > posting: You can't design protocol mechanisms which do not consider the variety of cases that might exist. > With respect to the method used to classify service request within the > four cathegories, a > possibility is that the home domain, at registration time, sends > information to the visited domain > on the requirements to meet to locally execute a given set of > services for that specific user. If > the visited domain supports such requirements ==> those services can > be executed locally. This seems dubious. It assumes some kind of simple classification of services which is unlikely to exist, and it also assumes that there is some kind of transfer of service logic from one domain to another. I think we have already discussed that this is really far fetched, both technically and politically. > > > Optimizing a system for the special case where (1) both caller and > > called party have home domains that are far, (2) they are both > > roaming > > in visiting domains that are close, (3) there are no other proxies > > on > > the path which record-route, seems like you are optimizing for the > > wrong > > case. > > First of all: we are not "optimizing" a system, here: we are adding a > feature, that can be useful to "optimize" a given set of cases. > > Let's make a simpler (and very common) example: > an Italian mobile roaming to Australia, that wants to call a (local !) > Taxy: is this the wrong case ? (In that case I'm wrong myself, because > I did it in Adelaide!!! :-)) This is a good example. I have no problem if, when a user moves somewhere else, the user decides to select a new ASP for providing certain services. This ASP has its own proxies and application servers, which may or may not be physically local to the user. The choice is ultimately the end users. My point is that I disagree with forcing users to obtain services through a certain proxy just because that service provider is also providing them with their IP level mobility services. I have no problems allowing users to choose different service providers at will, including the one providing the IP mobility services, if they have something compelling to offer, such as the service you desribe above (basically, a dial plan service). > > This need not be the case. In a scenario > > with a smoother handover, I can imagine a brief period where the > > roaming > > mobile has both addresses - one in the old domain, one in the new. > > When > > it obtains the new one, it does a re-INVITE to *add* a new media > > stream > > targeted to the new address. This means it will get both stream of > > packets during this transition period. Once these new packets start > > arriving, it can do a re-INVITE again, turning off the stream > > targeted > > to the old address. It can then release the old address. > > Sorry, but I think you missed the target. > > The problem is only related to the in-flight packets. > If I' m in the position of keeping the two address active for a while, > I will get the in-flight packets on the old > address anyway !!!! I don' t need any duplicte invite !!! You would if usage of that extra old address was costing you money, or it would cease to be possible to use it after some time. As I said, I am not sure if this is how IP mobility handover is accomplished. > > The problem comes when I lose the old address and there are some > already in-flight packets addressed to it. > The number of in-flight packets is proportional to the time needed to > make the other endpoint aware of the new address. > No duplicate Invites or whatever can help. At the risk of causing even more controversy and flames, I'll note that this problem is occuring because you are using an application layer mobility service for a network layer mobility need. If you were using an IP layer mobility service which allowed you to tell the network which owned your old address that you have moved, and thus to forward packets to your new address, you would not have this problem. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 15:20:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09696 for ; Fri, 19 May 2000 15:20:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A10344381; Fri, 19 May 2000 15:12:29 -0400 (EDT) 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 A44FC44357 for ; Fri, 19 May 2000 15:12:26 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 19 15:18:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id EB08944344; Fri, 19 May 2000 15:05:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C2AB644341 for ; Fri, 19 May 2000 15:05:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 114AF52C4; Fri, 19 May 2000 15:05:28 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 2FEBC52AB for ; Fri, 19 May 2000 15:05:25 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri May 19 15:03:38 EDT 2000 Received: from thumper.research.telcordia.com ([128.96.41.1]) by dusty; Fri May 19 15:03:37 EDT 2000 Received: from research.telcordia.com (shim-pc [192.4.8.82]) by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA10119; Fri, 19 May 2000 15:03:30 -0400 (EDT) Message-ID: <39258FFF.6D51A10A@research.telcordia.com> Date: Fri, 19 May 2000 15:03:27 -0400 From: Hyong Sop Shim Organization: Telcordia Technologies X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Vakil, Mohammad" , sip@lists.research.bell-labs.com, "'Mohammad.Vakil@outreachtech.com'" Subject: Re: [SIP] Multimedia Conferencing using SIP References: <410B13D70EB2D211827E00E0291E9FF7B2BCF4@ORT-MAIL> <39238277.963763CC@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > No extensions needed for central conference servers. It works just like > it does in the PSTN - you dial a number which corresponds to a port on a > bridge. In the case of SIP, you would INVITE to a URL corresponding to a > port on the conference server, like sip:conference33287372@mcu.com. The > result appears as a point to point SIP call as far as your UA is > concerned, but the server is mixing media and sending the mixed media to > your UA. You will learn the identity of the other participants through > RTCP CSRC. > > How do you know the right URL to send an INVITE to? Well, how do you > know what number to dial for a conference in PSTN? You're told out of > band. URLs can be included in emails, web pages, whatever. > In "SIP Call Control Services," the underlying model for establishing a conference seems to be that it is the responsibility of the invited user to send INVITE requests to the existing conference participants. That is, in a conference that is comprised of User A, B, and C, say A wishes to add D to the conference. According to the "SIP Call Control Services," A invites D, who, in turn, sends INVITE requests to B and C. Why is this model preferred over another model, in which the existing conference participants send INVITE requests to the invited? --Hyong Shim _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 15:22:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09762 for ; Fri, 19 May 2000 15:22:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 96C394439B; Fri, 19 May 2000 15:14:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E778D44399 for ; Fri, 19 May 2000 15:14:54 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA02808; Fri, 19 May 2000 15:23:24 -0400 (EDT) Message-ID: <39259728.EA530B97@dynamicsoft.com> Date: Fri, 19 May 2000 15:34:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: Adam.Roach@Ericsson.com, Jorgen.Bjorkner@hotsip.com, gmorrow@nortelnetworks.com, giuseppe.ricagni@italtel.it, mat@cisco.com, sip@lists.bell-labs.com Subject: Re: [SIP] Forcing call setup through home proxy (solution?) References: <200005191702.MAA21274@b04a45.exu.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sean Olson wrote: > > > Can't the Request-URI be used to achieve this functionality? > > > Yes, for a single hop. If you want to route your messsage through multiple hops, > you can either do what Adam suggested or use Route: headers in the INVITE message. I prefer > the later because it would require the least number of changes to existing proxies. Correct. If you send a request to any proxy, where the request-URI does not match the domain of the proxy, that proxy is supposed to forward the request to the proxy indicated in the request URI. In fact, that proxy could also forward, through its own configuration, to another proxy, which could then forward to the proxy in the request URI. But, if you want the UAC to specify multiple hops, use Route header. Adam wrote: > At the third bakeoff, I went around to a number of people and > asked how their proxies would behave if my client did this sort of > thing. I got a variety of mixed answers, none of which were > very encouraging. Some people wouldn't process it, for example, > unless it had a To: tag (since routes can't appear on leg > setup messages, or so goes the thinking). Most would completely > forgo their internal logic and blindly forward the message > (thus making their purpose only to add to the number of hops > in the call signalling route). Checking for tags and only obeying Route if there is a tag is probably not a good idea. It was not meant for this purpose. I think what is desired by that hack is to ensure that a Route is being followed only if it was one created by the proxy in a Record-Route. We had discussed, at the bakeoff, some kind of opaque token which would need to be returned along with the Route headers, which the proxy could use to confirm this. I believe that is a much better approach than checking for the tag. I'll note that verifying that the Route header is the result of insertion of Record-Route is at odds with Jorgens suggestion of using Route to force traversal through proxies for purpose of services. I believe that there is no way to reconcile these at the protocol level; it is a matter of local policy. Just like some MTAs don't support mail relay, and others do, so it is with obeying Route headers inserted by a UA without having seen a Record-Route first. In Jorgens example, this local proxy is presumably aware that it is there just because of mobility, and that users will want to get to their home proxies, and thus obey the Route header even if its in a new request. Adam later wrote: > So, what if we specified a fairly simple username convention > stating that proxies MAY do something similar; for example, > you could send something like: > > INVITE sip:jorgen.bjorkner%40ericsson.com@firewall.mycompany.com SIP/2.0 I don't see what this buys you above using Route. You are basically doing exactly the same thing as Route, but gluing the route headers together through URL encoding and then putting them in the request URI. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 15:34:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09985 for ; Fri, 19 May 2000 15:34:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A4392443C6; Fri, 19 May 2000 15:26:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 820A544366 for ; Fri, 19 May 2000 15:26:21 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA02841; Fri, 19 May 2000 15:35:12 -0400 (EDT) Message-ID: <392599EF.9EC7BFCF@dynamicsoft.com> Date: Fri, 19 May 2000 15:45:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL clarification for user paramater References: <39243951.FCC5DE10@lucent.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote: > > Jonathan/Henning: > > In RFC2543bis, section 2, 2nd last paragraph on page 17, you say: > > "The user parameter value "np-queried" indicates that the user part > contains a telephone number AND that the number reflects the result > of a query to the local number portability database". > > However, in Figure 3 on page 18, the BNF for user-param is: > > user-param = "user="("phone" | "ip") > > Should it be modified to: > > user-param = "user="(("phone" | "np-queried") | "ip") > > A look at the archives indicate that Jonathan and Marc Petit-Huguenin > had a thread on this around May 10, 2000 with Jonathan stating that > there was no consensus on if this was the right way to do this. Any > updates? None I've seen. I have no problem with the idea of saying that some kind of query has been done, but this particular solution is very specific to LNP, and I think there is a bigger picture. I would argue that the need for this thing at all arises because the telephone network uses equivalently formatted numbers to refer to two things - names and actual routing numbers (i.e., addresses). Its sort of like what would have happened if IP addresses and domain names were the same in syntax and formatting, such that you couldn't tell one from the other without checking with some database. The purpose of LNP is much like DNS, to translate an abstract name to a real routable address. Now, in the world of URLs, the namespace (or abstractly, the address space) of the content of the URL is defined by the scheme. If we view "numbers as names" and "numbers as addresses" as difference "namespaces", the theoretically correct way to indicate that LNP has been done is by defining a new URL scheme for the two: tel:18005551212 and rn:17325551212 where LNP (or 800 number lookup in this case) is used to translate. I am not proposing to do this, since practically speaking, its a pain. But I'd like something more generic to indicate the namespace that the number fits into. I don't exactly know what or how to do this. Perhaps this is really just phone-context, with the context being "routing-number" once translated? -Jonathan R. > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > IN Architecture and Internet Software Group > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 > 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 -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 15:38:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10040 for ; Fri, 19 May 2000 15:38:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9747443A5; Fri, 19 May 2000 15:30:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1D0ED44394 for ; Fri, 19 May 2000 15:30:31 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA02877; Fri, 19 May 2000 15:39:21 -0400 (EDT) Message-ID: <39259AE8.2635625B@dynamicsoft.com> Date: Fri, 19 May 2000 15:50:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Giuseppe Ricagni , sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005112221.PAA22239@nasnfs.eng.sun.com> <14620.41878.763300.49818@thomasm-u1.cisco.com> <392019ED.A97587BF@italtel.it> <14624.18086.838767.469304@thomasm-u1.cisco.com> <392080EB.5047280@dynamicsoft.com> <39216923.37622CD3@italtel.it> <392221A5.CB601993@dynamicsoft.com> <39228CBB.CE13BE3A@italtel.it> <39238524.A3263087@dynamicsoft.com> <3923E6CA.941FA323@italtel.it> <14628.8344.56504.279408@thomasm-u1.cisco.com> <39243B1F.E6ED1678@italtel.it> <14628.17534.120289.333326@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > > * When the caller is roaming, under certain circumstances (related to the type of value added > > services required & the set of services supported by the visited network & the possibility to > > transfer a user profile--see my previous messages) > > I don't know what services the roaming network > wants to provide -- other than trying to shoehorn > themselves into the call. Even if, there is nothing > to prevent me from obtaining those service even if > it's routed through my home proxy first. There are two different cases - one where the proxy is asking to be on the call path for an existing call, and the other, where the proxy wishes to be the local outbound (or inbound) proxy for outgoing (or incoming) calls. I agree totally that the former - shoehorning into an existing call - makes little sense technically. For the latter case, I think the roaming proxy is simply another ASP. I can see reasons why I might want to use them for some calls, and not for others. I see no reason to prevent a user from using those proxies, but I don't see a reason for forcing them to use them. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 16:23:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10529 for ; Fri, 19 May 2000 16:23:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E87D144361; Fri, 19 May 2000 16:15:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 43CF544357 for ; Fri, 19 May 2000 16:15:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA03158; Fri, 19 May 2000 16:23:54 -0400 (EDT) Message-ID: <3925A559.19C02D8@dynamicsoft.com> Date: Fri, 19 May 2000 16:34:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Clarification of 302 handling References: <200005191700.MAA21271@b04a45.exu.ericsson.se> <39257C47.75917023@cs.columbia.edu> <39258526.882F0626@dynamicsoft.com> <39258427.FA3783F7@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Wording added: > > The new request can take two different forms. In the first approach, > the \header{To}, \header{From}, \header{CSeq} and \header{Call-ID} > header fields in the new request are the same as in the original > request, with a new \header{branch} identifier in the \header{Via} > header field. , and the new address in the \header{Request-URI}. > Proxies {\SHOULD} follow this behavior and UACs {\MAY}. \MUST follow this behavior (they can't change the Call-ID, To, From or CSeq, not any other choice then) -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 16:24:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10542 for ; Fri, 19 May 2000 16:24:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BB0644389; Fri, 19 May 2000 16:16:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9164A44386 for ; Fri, 19 May 2000 16:16:13 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA03162; Fri, 19 May 2000 16:25:05 -0400 (EDT) Message-ID: <3925A59F.9D6DFE74@dynamicsoft.com> Date: Fri, 19 May 2000 16:35:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Henning Schulzrinne , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Clarification of 302 handling References: <200005191700.MAA21271@b04a45.exu.ericsson.se> <39257C47.75917023@cs.columbia.edu> <39258526.882F0626@dynamicsoft.com> <39258427.FA3783F7@cs.columbia.edu> <39258B9C.4D96C8B@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Not neccesarily. No reason that the UA can't do exactly the same as a proxy does. I argued in a previous email that there are advantages to this, since it means as the new request is forwarded, proxies can recognize this as the same transaction and not forward to addresses they already tried. -Jonathan R. Igor Slepchin wrote: > > I believe UAC should increase CSeq if it decides to keep the original > To, From and Call-ID in the new request. > > --- > Igor Slepchin > > Henning Schulzrinne wrote: > > Wording added: > > > > The new request can take two different forms. In the first approach, > > the \header{To}, \header{From}, \header{CSeq} and \header{Call-ID} > > header fields in the new request are the same as in the original > > request, with a new \header{branch} identifier in the \header{Via} > > header field. Proxies {\SHOULD} follow this behavior and UACs {\MAY}. > > UAs {\MAY} also use the \header{Contact} information for the \header{To} > > header field, as well as a new \header{Call-ID} value. > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 16:50:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10883 for ; Fri, 19 May 2000 16:50:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 32E11443A7; Fri, 19 May 2000 16:42:28 -0400 (EDT) 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 B0D9B44366 for ; Fri, 19 May 2000 16:42:25 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 19 16:48:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 43F2744344; Fri, 19 May 2000 16:35:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 1901544341 for ; Fri, 19 May 2000 16:35:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 56B0952C4; Fri, 19 May 2000 16:35:29 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2C43952AB for ; Fri, 19 May 2000 16:35:26 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri May 19 16:33:16 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Fri May 19 16:33:15 EDT 2000 Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA03201; Fri, 19 May 2000 16:34:13 -0400 (EDT) Message-ID: <3925A7C3.D1422138@dynamicsoft.com> Date: Fri, 19 May 2000 16:44:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hyong Sop Shim Cc: "Vakil, Mohammad" , sip@lists.research.bell-labs.com, "'Mohammad.Vakil@outreachtech.com'" Subject: Re: [SIP] Multimedia Conferencing using SIP References: <410B13D70EB2D211827E00E0291E9FF7B2BCF4@ORT-MAIL> <39238277.963763CC@dynamicsoft.com> <39258FFF.6D51A10A@research.telcordia.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hyong Sop Shim wrote: > > Jonathan Rosenberg wrote: > > > No extensions needed for central conference servers. It works just like > > it does in the PSTN - you dial a number which corresponds to a port on a > > bridge. In the case of SIP, you would INVITE to a URL corresponding to a > > port on the conference server, like sip:conference33287372@mcu.com. The > > result appears as a point to point SIP call as far as your UA is > > concerned, but the server is mixing media and sending the mixed media to > > your UA. You will learn the identity of the other participants through > > RTCP CSRC. > > > > How do you know the right URL to send an INVITE to? Well, how do you > > know what number to dial for a conference in PSTN? You're told out of > > band. URLs can be included in emails, web pages, whatever. > > > > In "SIP Call Control Services," the underlying model for establishing a conference seems to be that it is the responsibility of the invited user to send INVITE requests to the existing conference participants. That is one model, but not the only one SIP provides. SIP has four ways to do multiparty conferencing: 1. dialup conference bridge: call the bridge just like you call a person. Conference is identified by request URI. Works with rfc2543 - no extensions needed. 2. distributed multiparty conferencing - no server. Fully distributed. This is what is described in the now-expired draft, and is work in progress. 3. multicast conferences - you can run your conference on multicast. Simply INVITE the person to join the multicast session. Works with baseline SIP. In fact, this was the initial purpose of SIP. In this case, there is not a full mesh of SIP signaling. 4. 3-way with local MC/MP function: A and B are talking. A wishes to add C to the call. A can simply call C, but also act as a mixer, so that the media it sends to B contains the A+C media, and the media to C is the A+B media. RTCP CSRC indicate who is in the conference. This also works with baseline SIP. It imposes additional burden on the UA, but otherwise provides this standard feature in a simple way. There is no preferred way. It depends on the particular application. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 16:53:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10897 for ; Fri, 19 May 2000 16:53:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E66FF44386; Fri, 19 May 2000 16:44:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6855F44366 for ; Fri, 19 May 2000 16:44:50 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA03352; Fri, 19 May 2000 16:53:46 -0400 (EDT) Message-ID: <3925A901.2A0E99F5@dynamicsoft.com> Date: Fri, 19 May 2000 16:50:09 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Henning Schulzrinne , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Clarification of 302 handling References: <200005191700.MAA21271@b04a45.exu.ericsson.se> <39257C47.75917023@cs.columbia.edu> <39258526.882F0626@dynamicsoft.com> <39258427.FA3783F7@cs.columbia.edu> <39258B9C.4D96C8B@dynamicsoft.com> <3925A59F.9D6DFE74@dynamicsoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit If a UA does this, any proxy compliant to RFC2543 will consider the new request a retransmission of the old one. Top Via is not part of the call leg (aka transaction) id according to the RFC. Besides, I see absolutely no point in making the UAC keep the Cseq the same: any proxy interested in following call progress should be able to match the re-INVITEs with increased CSeq anyway so why not increase the CSeq and make everything consistent? --- Igor Slepchin Jonathan Rosenberg wrote: > > Not neccesarily. No reason that the UA can't do exactly the same as a > proxy does. I argued in a previous email that there are advantages to > this, since it means as the new request is forwarded, proxies can > recognize this as the same transaction and not forward to addresses they > already tried. > > -Jonathan R. > > Igor Slepchin wrote: > > > > I believe UAC should increase CSeq if it decides to keep the original > > To, From and Call-ID in the new request. > > > > --- > > Igor Slepchin > > > > Henning Schulzrinne wrote: > > > Wording added: > > > > > > The new request can take two different forms. In the first approach, > > > the \header{To}, \header{From}, \header{CSeq} and \header{Call-ID} > > > header fields in the new request are the same as in the original > > > request, with a new \header{branch} identifier in the \header{Via} > > > header field. Proxies {\SHOULD} follow this behavior and UACs {\MAY}. > > > UAs {\MAY} also use the \header{Contact} information for the \header{To} > > > header field, as well as a new \header{Call-ID} value. > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 May 19 17:06:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11053 for ; Fri, 19 May 2000 17:06:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D65CB443AC; Fri, 19 May 2000 16:59:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3B96944370 for ; Fri, 19 May 2000 16:59:06 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA03441; Fri, 19 May 2000 17:06:50 -0400 (EDT) Message-ID: <3925AF69.D179EE21@dynamicsoft.com> Date: Fri, 19 May 2000 17:17:29 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Henning Schulzrinne , Sean Olson , sip@lists.bell-labs.com Subject: Re: [SIP] Clarification of 302 handling References: <200005191700.MAA21271@b04a45.exu.ericsson.se> <39257C47.75917023@cs.columbia.edu> <39258526.882F0626@dynamicsoft.com> <39258427.FA3783F7@cs.columbia.edu> <39258B9C.4D96C8B@dynamicsoft.com> <3925A59F.9D6DFE74@dynamicsoft.com> <3925A901.2A0E99F5@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > If a UA does this, any proxy compliant to RFC2543 will consider the new > request a retransmission of the old one. Top Via is not part of the call > leg (aka transaction) id according to the RFC. Its only consider a retransmission if the request URI is the same (recall the new rules for loop detection). If the request URI is the same, then you get exactly what you want - the proxy treats this as a retransmission or rejects it as a merged request. We've already tried that address. Besides, I see absolutely > no point in making the UAC keep the Cseq the same: any proxy interested > in following call progress should be able to match the re-INVITEs with > increased CSeq anyway so why not increase the CSeq and make everything > consistent? I am not advocating using the same CSeq for purposes of tracking calls, but for purposes of unifying the way a proxy does recursion and the way a UAC does recursion. You get the benefit of not trying places again you've already tried. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 17:13:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11102 for ; Fri, 19 May 2000 17:13:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EECC0443D3; Fri, 19 May 2000 17:05:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 831E6443CF for ; Fri, 19 May 2000 17:05:07 -0400 (EDT) Received: from dynamicsoft.com (1Cust22.tnt3.freehold.nj.da.uu.net [63.25.172.22]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA03481; Fri, 19 May 2000 17:13:58 -0400 (EDT) Message-ID: <3925B115.DA580341@dynamicsoft.com> Date: Fri, 19 May 2000 17:24:37 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Question abt. Content-Disposition References: <652568E4.001C1EAC.00@sampark.hss.hns.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The purpose of this is that we have found that Content-Type defines the *syntax* of the content, but not the semantics. In some cases, one implies the other, and in other cases, they don't. As an example, if a receive an INVITE with a multipart, and one of the multiparts contains a URI list, what is that URI list for? Is it content to be displayed (like a jpeg), or is it a way to fetch the session description? The idea with Content-Disposition is that it tells you the purpose of the content (and also if its optional or mandatory). Another application of it is in: http://search.ietf.org/internet-drafts/draft-lennox-sip-reg-payload-00.txt which calls it Content-Purpose, but the need is the same - what is the purpose of the payload in the registration message. Some of the possible purposes include: session (like SDP) inline (display to the user, like JPEG or html) authorization (like an OSP token) sip-cgi (a CGI script) cpl (A CPL script) -Jonathan R. archow@hss.hns.com wrote: > > Hi, > > According to the description of Content-Dispotion (C-D) header, its role is > to tell the UA whether the message (part) has to be > necessarily idenfied or not by the UA. > > So, if I had a MIME header with 2 parts, with my first part being an ISUP > encoded payload and my second part being a message which I really dont care > if the UA understands or not, I do: > > --- begin ---- > INVITE sip:01628434456@dcs1.nortelnetworks.com SIP/2.0 > > Content-Type: multipart/mixed; boundary=unique-boundary-1 > > --unique-boundary-1 > Content-type:application/isup > Content-Transfer-Encoding: binary > > .. ... > > --unique-boundary-1 > Content-type:application/moohaa > Content-Diposition:inline;handling=optional > > I dont really care if you understand me or not > > --unique-boundary-1-- > > --- end --- > > Is the above correct ? > > I could find any reference to what the disposition type token is all abt, > and when I should specify which. > Also, what is the extension-param in disposition type for ? > > If all its use is to tell the UA to mandatorily/optionally understand a > message part, then isnt > > Content-Disposition - "Content-Disposition" ":" dispositon-type > disposition-type = "optional" | "required" > enough ? > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 19 17:32:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11213 for ; Fri, 19 May 2000 17:32:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61C7444366; Fri, 19 May 2000 17:24:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 8961244357 for ; Fri, 19 May 2000 17:24:44 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA24296; Fri, 19 May 2000 16:34:08 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA23627; Fri, 19 May 2000 16:31:43 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 19 May 2000 16:31:43 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790CA@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: "'Lars Berggren'" , sip@lists.bell-labs.com Subject: RE: [SIP] Comments on Session Timer draft Date: Fri, 19 May 2000 16:31:42 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The session timer draft (draft-ietf-sip-session-timer-01.txt) as written is asymmetric, in that it seems to assume that the UAC is more likely to impolitely abandon the session, and that the proxies and UAS need some way to recover from that. I'd like to see the reverse case addressed as well: where the UAC (or a proxy) is distrustful of the UAS, and needs some way to clean up if the UAS impolitely abandons the session. I suppose the keep-alive re-INVITES can still be sent by the UAC, and it will be the lack of a response (rather than the lack of an incoming message) which informs the UAC and the proxies that the UAS has dropped off. But in regard to the Open Issues list, I think the answer to the second issue (should we allow the UAS to insert a Require: timer header?) should be YES. Just like the UAS can reject a call that won't be set up with a session timer, the UAC should be able to avoid having a call set up without a session timer. It would do this by using the "Require: timer" header rather than the weaker "Supported: timer" header. If the UAS cannot handle the feature, the call would be rejected, rather than set up without the (demanded) timer feature. And for the third Open Issue on the list, a proxy should also be able to add the "Require: timer" header if the UAC merely "supports" but does not "require" the feature. Just like the proxy can tighten up the timing requirements by lowering the expiration time, it should be able to tighten up the requirements by making the feature "required" rather than merely "supported". Then, if the UAS did not implement that feature, the request would be denied. [This might take some more thought; it would seem odd to the UAC for its request to end up denied for lack of a feature it did not require.] Alternatively, maybe there's no support needed in the UAS at all: the re-INVITES are all sent from the UAC, and the UAS needn't know anything about the feature to process them. This is similar to what Lars Berggren < mailto:lars.berggren@intertex.se> proposes: >> For the Session Timer to be applied for a call leg, the specifications in the draft requires that both the UAC and UAS understand the extension (See example 8.5). However, since the keep-alive mechanism is achieved by sending 'standard' re-INVITEs, it is sufficient (and useful) that at least one of the parties is aware of the Session Timer to accomplish a keep-alive mechanism. The usefulness of such an approach is for example when a UAC supports 'timer', a stateful proxy server, SPS, wants to apply a Session Timer to the call and the UAS doesn't understand the extension. Here, the call will be setup without Session Timer even though the SPS wanted one and the UAC could do the necessary re-inviting. The UAS doesn't need to know about Session Timers in order to process re-INVITEs properly. The only thing that forces that the UAS have to be aware of the Session Timer is the statement in the draft that the UAS SHOULD send BYE if no re-INVITE has arrived when the session expires. Well, the UAC could do the sending of the BYE if it does not intend to update the timer. So, to solve this problem, I would like to propose that the SPS could add a Session-Expires header in the response if the SPS knows the UAC supports 'timer' and the response does not contain a Session-Expires header. << At any rate, I'd like the draft to address the cases where any of the UAC/UAS/proxy *require* the session timer feature. I'd consider it OK for the session to not get set up if the session timer feature weren't supported by all (or enough) of the UAs, but not OK for the session to get set up without a timer if one were required anywhere along the path. Also, the third to the last paragraph in section 4 (beginning "A UAC may use the refreshing re-INVITE as a normal SIP re-INVITE ...") makes no sense to me. It talks about sending an *updated* session description and using the origin field to indicate the description is *unchanged*. Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 19 18:36:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11532 for ; Fri, 19 May 2000 18:36:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8BDEF44368; Fri, 19 May 2000 18:28:37 -0400 (EDT) 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 78D5544357 for ; Fri, 19 May 2000 18:28:34 -0400 (EDT) Received: from valin (dhcp137.spud.softarmor.com [192.168.39.137]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id EAA26342; Sat, 20 May 2000 04:37:57 -0500 From: "Dean Willis" To: "Michael Thomas" Cc: "IETF SIP" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) Date: Fri, 19 May 2000 17:35:09 -0500 Message-ID: <003401bfc1e2$7ccf6700$8927a8c0@spud.softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2919.6600 In-Reply-To: <14628.24882.15278.231237@thomasm-u1.cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id SAA11532 Ah. The networkstatus-aware proxy is effectively advising the SIP user of congestion in the DiffServ network. Kind of like those radio announcers that say "Highway 18 is shut down again -- please use surface streets or just stay home". The real question is to define a mechanism that allows the health of the network to be assessed in some sort of meaningful way so that this knowledge may be made available to the UAC. -- Dean > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, May 18, 2000 4:32 PM > To: Dean Willis > Cc: IETF SIP; Michael Thomas > Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force > in Adelaide) > > > Dean Willis writes: > > Consider it in an aggregation model, like a donut. The chewy > outside parts of the donut are controlled by IntServ. Traffic > leaps across the DiffServ donut-hole only if the heuristic > process thinks (IE, is reasonably sure) that there is adequate bandwidth. > > OK, but I still don't see what that has to do > with proxies. That sounds like something an > edge router would do before it admits diffserv > traffic into the diffserv core. Proxies are even > more clueless because they never see the actual > traffic patterns. > > Mike > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Sat May 20 09:10:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29335 for ; Sat, 20 May 2000 09:10:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 07C8144357; Sat, 20 May 2000 09:02:41 -0400 (EDT) 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 6C8F744351 for ; Sat, 20 May 2000 09:02:38 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FUV00C010L7U3@firewall.mcit.com> for sip@lists.bell-labs.com; Sat, 20 May 2000 13:10:19 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FUV009G90L7RU@firewall.mcit.com>; Sat, 20 May 2000 13:10:19 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FUV00D010KCOU@dgismtp03.wcomnet.com>; Sat, 20 May 2000 13:09:48 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FUV00D010KAOL@dgismtp03.wcomnet.com>; Sat, 20 May 2000 13:09:48 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FUV00L6S0K9P7@dgismtp03.wcomnet.com>; Sat, 20 May 2000 13:09:46 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Sat, 20 May 2000 13:10:16 +0000 Content-return: allowed Date: Sat, 20 May 2000 13:10:14 +0000 From: "Sinnreich, Henry" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for ce in Adelaide) To: "'Dean Willis'" , Michael Thomas Cc: IETF SIP Message-id: <75C79E507864D3118AFC00805FEAB7D85B26A1@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA29335 >The real question is to define a mechanism that allows the >health of the network to be assessed in some sort of >meaningful way so that this knowledge may be made available to the UAC. The model in actually deals with this problem. Upon failure of the RSVP request, the telephony endpoint can alert the user: "QoS cannot be provided, would you like to proceed with the call". The awareness of the originating SIP server, though we not explicitly discussed is can also be dealt with by the model. We have shown that the transit network providing DiffServ to the edge networks have to police the ingress traffic, to make sure that that the premium QoS traffic injected does not exceed the SLS. This job is done by the border routers in the transit networks. The border router can alert the edge router in the access network when excess traffic is being passed, and this could be also used to alert the bandwidth and policy manager in the access network. The policy manager will refuse to authorize new requests for QoS enabled voice calls coming from application servers, including the SIP server. The SIP server will therefore know... Please let me know if there are any weaknesses in the model, as shown in the diagrams and call flows. http://ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-01.t xt Henry >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com] >Sent: Friday, May 19, 2000 5:35 PM >To: Michael Thomas >Cc: IETF SIP >Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task >force in Adelaide) > > > >Ah. The networkstatus-aware proxy is effectively advising the >SIP user of congestion in the DiffServ network. Kind of like >those radio announcers that say "Highway 18 is shut down again >-- please use surface streets or just stay home". > >The real question is to define a mechanism that allows the >health of the network to be assessed in some sort of >meaningful way so that this knowledge may be made available to the UAC. > >-- >Dean > > > >> -----Original Message----- >> From: Michael Thomas [mailto:mat@cisco.com] >> Sent: Thursday, May 18, 2000 4:32 PM >> To: Dean Willis >> Cc: IETF SIP; Michael Thomas >> Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP >Security task force >> in Adelaide) >> >> >> Dean Willis writes: >> > Consider it in an aggregation model, like a donut. The chewy >> outside parts of the donut are controlled by IntServ. Traffic >> leaps across the DiffServ donut-hole only if the heuristic >> process thinks (IE, is reasonably sure) that there is >adequate bandwidth. >> >> OK, but I still don't see what that has to do >> with proxies. That sounds like something an >> edge router would do before it admits diffserv >> traffic into the diffserv core. Proxies are even >> more clueless because they never see the actual >> traffic patterns. >> >> Mike >> Hfæj)bz b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿(tm)¨¥(tm)©ÿ-+-SwèþÈ© > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat May 20 09:26:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29390 for ; Sat, 20 May 2000 09:26:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A6734438E; Sat, 20 May 2000 09:18:39 -0400 (EDT) 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 6DDC544370 for ; Sat, 20 May 2000 09:18:34 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FUV00C011BR7K@firewall.mcit.com> for sip@lists.bell-labs.com; Sat, 20 May 2000 13:26:15 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FUV00B3U1BR7G@firewall.mcit.com>; Sat, 20 May 2000 13:26:15 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FUV00I011AWIA@dgismtp03.wcomnet.com>; Sat, 20 May 2000 13:25:44 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FUV00I011AWI9@dgismtp03.wcomnet.com>; Sat, 20 May 2000 13:25:44 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FUV00L901AGOX@dgismtp03.wcomnet.com>; Sat, 20 May 2000 13:25:29 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Sat, 20 May 2000 13:25:59 +0000 Content-return: allowed Date: Sat, 20 May 2000 13:25:56 +0000 From: "Sinnreich, Henry" Subject: FW: SIP DiffServ (was RE: [SIP] Minutes of SIP Security task for ce in Adelaide) To: IETF SIP , Michael Thomas , "'Dean Willis'" Message-id: <75C79E507864D3118AFC00805FEAB7D85B26A4@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA29390 Sorry for the resend - there were typos. Henry >The real question is to define a mechanism that allows the >health of the network to be assessed in some sort of >meaningful way so that this knowledge may be made available to the UAC. The model in actually deals with this problem. Upon failure of the RSVP request, the telephony endpoint can alert the user: "QoS cannot be provided, would you like to proceed with the call?". The awareness of the originating SIP server, though not explicitly discussed, can also be dealt with by the model. We have shown that the transit networks providing DiffServ to the edge networks, have to police the ingress traffic, to make sure that the premium QoS traffic injected does not exceed the SLS. This job is done by the border routers in the transit networks. The border router can alert the edge router in the access network when excess traffic is being passed, and this could be also used to alert the bandwidth and policy manager in the access network. The policy manager will refuse to authorize new requests for QoS enabled voice calls coming from application servers, including the SIP server. The SIP server will therefore know... Please let me know if there are any weaknesses in the model, as shown in the diagrams and call flows. http://ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-01.t Henry >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com] >Sent: Friday, May 19, 2000 5:35 PM >To: Michael Thomas >Cc: IETF SIP >Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task >force in Adelaide) > > > >Ah. The networkstatus-aware proxy is effectively advising the >SIP user of congestion in the DiffServ network. Kind of like >those radio announcers that say "Highway 18 is shut down again >-- please use surface streets or just stay home". > >The real question is to define a mechanism that allows the >health of the network to be assessed in some sort of >meaningful way so that this knowledge may be made available to the UAC. > >-- >Dean > > > >> -----Original Message----- >> From: Michael Thomas [mailto:mat@cisco.com] >> Sent: Thursday, May 18, 2000 4:32 PM >> To: Dean Willis >> Cc: IETF SIP; Michael Thomas >> Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP >Security task force >> in Adelaide) >> >> >> Dean Willis writes: >> > Consider it in an aggregation model, like a donut. The chewy >> outside parts of the donut are controlled by IntServ. Traffic >> leaps across the DiffServ donut-hole only if the heuristic >> process thinks (IE, is reasonably sure) that there is >adequate bandwidth. >> >> OK, but I still don't see what that has to do >> with proxies. That sounds like something an >> edge router would do before it admits diffserv >> traffic into the diffserv core. Proxies are even >> more clueless because they never see the actual >> traffic patterns. >> >> Mike >> Hfæj)bz b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿(tm)¨¥(tm)©ÿ-+-SwèþÈ© > _______________________________________________ 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 Sat May 20 13:59:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00534 for ; Sat, 20 May 2000 13:59:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D202844351; Sat, 20 May 2000 13:51:13 -0400 (EDT) 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 EF65D44338 for ; Sat, 20 May 2000 13:51:10 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA10887; Sat, 20 May 2000 10:58:56 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA26776; Sat, 20 May 2000 10:58:49 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14630.53848.996840.659043@thomasm-u1.cisco.com> Date: Sat, 20 May 2000 10:58:48 -0700 (PDT) To: "Adam B. Roach" Cc: Jorgen.Bjorkner@hotsip.com (=?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?=), giuseppe.ricagni@italtel.it ('Giuseppe Ricagni '), mat@cisco.com ('Michael Thomas '), sip@lists.bell-labs.com ('sip@lists.bell-labs.com ') Subject: Re: [SIP] Forcing call setup through home proxy (solution?) In-Reply-To: <200005191049.FAA08370@b04a24.exu.ericsson.se> References: <2160ABC55998D311821900508B2C14BB269D54@SPEED01> <200005191049.FAA08370@b04a24.exu.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/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Adam B. Roach writes: > Back in the day, you could manually route e-mail messages through > a variety of servers by specifying an email address of the format > adam.roach%internal_host@ericsson.com. Upon receiving this, > ericsson.com would turn the last % into an @ and continue > routing the message. This could be indefinitely chained > to produce something like adam.roach%host3%host2%host1@ericsson.com > which would route the message through ericsson.com, then host1, > then host2, and finally deliver it to host3. Would this not lead to the need for a SIP version of ORBS? Mike, half serious _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun May 21 03:42:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05400 for ; Sun, 21 May 2000 03:42:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C15444342; Sun, 21 May 2000 03:34:40 -0400 (EDT) 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 2E7FB4433E for ; Sun, 21 May 2000 03:34:37 -0400 (EDT) Received: from valin (dhcp137.spud.softarmor.com [192.168.39.137]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id NAA01052; Sun, 21 May 2000 13:44:14 -0500 From: "Dean Willis" To: "Sinnreich, Henry" Cc: "IETF SIP" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for cein Adelaide) Date: Sun, 21 May 2000 02:41:22 -0500 Message-ID: <000001bfc2f7$f5a67220$8927a8c0@spud.softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <75C79E507864D3118AFC00805FEAB7D85B26A1@ripexch001.mcit.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id DAA05400 Henry wrote: > Dean wrote: > >The real question is to define a mechanism that allows the > >health of the network to be assessed in some sort of > >meaningful way so that this knowledge may be made available to the UAC. > > The model in actually deals with this problem. > Upon failure of the RSVP request, the telephony endpoint can > alert the user: > "QoS cannot be provided, would you like to proceed with the call". Perhaps, but I'm trying to find a way to get knowledge about the state of the backbone network into an edge device WITHOUT using RSVP. It just occurred to met that this could also be used as a means of traffic shaping enterprise access to fit within the bounds of a slightly elastic SLA. Let's say CorpA has an SLA whereby they are allowed to admit up to an average of 1Mb/S of expedited traffic across any 10-minute window, and whatever their port will carry of best-effort. Here's one possible way: The access routers feeds class-usage counters periodically (say, 1 minute intervals) to a network management system. This NMS then calculates a sliding average for each traffic class. From the current average, it calculates the maximal steady-state bandwith allowable over the next ten minutes to stay within the SLA minus a safety margin. The NMS then divides this number by the average bandwith requirement of a phone call at this site, thereby generating a number which is roughly the equivalent of the number of calls that may be admitted RIGHT NOW without causing a violation of the SLA to occur. The NMS posts this data to a proxy, which then decrements this number for each additional call admitted. When a new estimate comes in, it replaces the current working number. If the working number drops to zero (or some low threhold to allow for emergency calls), calls are not admitted unlesss they appropriately marked "urgent". I suppose one could do a monte-carlo simulation of this and get a reasonable feel for the efficacy. -- Dean ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Sun May 21 22:41:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13740 for ; Sun, 21 May 2000 22:41:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F77E4433D; Sun, 21 May 2000 22:33:50 -0400 (EDT) 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 C7A1044336 for ; Sun, 21 May 2000 22:33:47 -0400 (EDT) Received: from nomsg.cisco.com (nomsg.cisco.com [192.168.221.45]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA16363; Sun, 21 May 2000 19:41:49 -0700 (PDT) Received: from cisco.com (caryfitz-dsl3.cisco.com [144.254.234.180]) by nomsg.cisco.com (Mirapoint) with ESMTP id AAA17539 (AUTH caryfitz); Sun, 21 May 2000 19:48:06 -0700 (PDT) Message-ID: <39289EA7.D0F727C3@cisco.com> Date: Sun, 21 May 2000 19:42:47 -0700 From: Cary FitzGerald Organization: Cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: "Sinnreich, Henry" , IETF SIP Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for cein Adelaide) References: <000001bfc2f7$f5a67220$8927a8c0@spud.softarmor.com> Content-Type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA13740 This technique is the moral equivalent of H.323 GK-based bandwidth management. The results from that set of experiences leaves the proposition unproven. To my way of thinking, there are a number of inherent weaknesses in the model (for example, in your scenario, you won't discover anything about the backbone, only something about the access routers). On the other hand, you don't need anything new in SIP itself to build such a proxy, right? Cary. Dean Willis wrote: > Henry wrote: > > Dean wrote: > > >The real question is to define a mechanism that allows the > > >health of the network to be assessed in some sort of > > >meaningful way so that this knowledge may be made available to the UAC. > > > > The model in actually deals with this problem. > > Upon failure of the RSVP request, the telephony endpoint can > > alert the user: > > "QoS cannot be provided, would you like to proceed with the call". > > Perhaps, but I'm trying to find a way to get knowledge about the state of the backbone network into an edge device WITHOUT using RSVP. > > It just occurred to met that this could also be used as a means of traffic shaping enterprise access to fit within the bounds of a slightly elastic SLA. > > Let's say CorpA has an SLA whereby they are allowed to admit up to an average of 1Mb/S of expedited traffic across any 10-minute window, and whatever their port will carry of best-effort. > > Here's one possible way: > > The access routers feeds class-usage counters periodically (say, 1 minute intervals) to a network management system. This NMS then calculates a sliding average for each traffic class. From the current average, it calculates the maximal steady-state bandwith allowable over the next ten minutes to stay within the SLA minus a safety margin. The NMS then divides this number by the average bandwith requirement of a phone call at this site, thereby generating a number which is roughly the equivalent of the number of calls that may be admitted RIGHT NOW without causing a violation of the SLA to occur. The NMS posts this data to a proxy, which then decrements this number for each additional call admitted. When a new estimate comes in, it replaces the current working number. If the working number drops to zero (or some low threhold to allow for emergency calls), calls are not admitted unlesss they appropriately marked "urgent". > > I suppose one could do a monte-carlo simulation of this and get a reasonable feel for the efficacy. > > -- > Dean > > Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ© _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 04:35:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27757 for ; Mon, 22 May 2000 04:35:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EC5644433B; Mon, 22 May 2000 04:27:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by lists.bell-labs.com (Postfix) with ESMTP id CCD8444336 for ; Mon, 22 May 2000 04:27:41 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4M8N0H02218 for ; Mon, 22 May 2000 10:23:00 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Mon, 22 May 2000 10:23:27 +0200 Received: from esealnt406-in.al.sw.ericsson.se ([153.88.251.29]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 22 May 2000 08:23:26 0000 (GMT) Received: from esealnt172.ericsson.se ([130.100.184.165]) by esealnt406-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Mon, 22 May 2000 10:21:55 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Mon, 22 May 2000 10:25:27 +0200 Message-ID: From: "Velibor Cakarevic (ECS)" To: sip@lists.bell-labs.com Subject: [SIP] Clarification of CSeq Date: Mon, 22 May 2000 10:10:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 May 2000 08:21:55.0906 (UTC) FILETIME=[CA905220:01BFC3C6] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com In the document draft-ietf-sip-call-flows-00.txt there is an example of a successful SIP to SIP session establishment (chapter 3.1.1). I wonder if the CSeq should not increase its value by one when a session is terminated with the BYE signal? In the draft example the Invite signal has the value CSeq: 1 INVITE and the bye signal CSeq: 1 BYE. Should it not be CSeq: 2 BYE? Assume that a User A sends 'INVITE' to a User B (CSeq: 1 INVITE). User B replies with '486 busy here' (CSeq: 1 INVITE). What should the value of CSeq be in 'ACK' from User A to User B? I think it should be CSeq: 2 ACK. ____________________________________________ Velibor Cakarevic _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 04:38:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27780 for ; Mon, 22 May 2000 04:38:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61C6444354; Mon, 22 May 2000 04:28:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id A364C4434C for ; Mon, 22 May 2000 04:28:40 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4M8PUO00183 for ; Mon, 22 May 2000 10:25:30 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Mon, 22 May 2000 10:23:27 +0200 Received: from esealnt406-in.al.sw.ericsson.se ([153.88.251.29]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 22 May 2000 08:23:26 0000 (GMT) Received: from esealnt172.ericsson.se ([130.100.184.165]) by esealnt406-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Mon, 22 May 2000 10:21:55 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Mon, 22 May 2000 10:25:27 +0200 Message-ID: From: "Velibor Cakarevic (ECS)" To: sip@lists.bell-labs.com Subject: [SIP] Clarification of CSeq Date: Mon, 22 May 2000 10:10:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 May 2000 08:21:55.0906 (UTC) FILETIME=[CA905220:01BFC3C6] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com In the document draft-ietf-sip-call-flows-00.txt there is an example of a successful SIP to SIP session establishment (chapter 3.1.1). I wonder if the CSeq should not increase its value by one when a session is terminated with the BYE signal? In the draft example the Invite signal has the value CSeq: 1 INVITE and the bye signal CSeq: 1 BYE. Should it not be CSeq: 2 BYE? Assume that a User A sends 'INVITE' to a User B (CSeq: 1 INVITE). User B replies with '486 busy here' (CSeq: 1 INVITE). What should the value of CSeq be in 'ACK' from User A to User B? I think it should be CSeq: 2 ACK. ____________________________________________ Velibor Cakarevic _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 05:40:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28344 for ; Mon, 22 May 2000 05:40:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A6774433F; Mon, 22 May 2000 05:32:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 518FC44336 for ; Mon, 22 May 2000 05:32:32 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA23715; Mon, 22 May 2000 10:38:30 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sip Mail List Date: Mon, 22 May 2000 10:25:28 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00052210383600.29678@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] Mime-Version and Content-Language in new Bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi, can i get confirmation that the mime-version and content-language headers should be present (or not) in the new bis please. I remember a thread on the validity of the content-language and thought the result was that it should not exist. It is still present in the new bis (May) along with the mime-version header but neither are mentioned in Appendix F, have a description of their use or are marked as new. thanx -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net gethin@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 May 22 06:23:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28504 for ; Mon, 22 May 2000 06:23:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4DC384436C; Mon, 22 May 2000 06:14:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id EBE7A44336 for ; Mon, 22 May 2000 06:14:39 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id QAA28021; Mon, 22 May 2000 16:35:30 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568E7.0039B7D5 ; Mon, 22 May 2000 16:00:26 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Velibor Cakarevic (ECS)" Cc: sip@lists.bell-labs.com Message-ID: <652568E7.0039B7AE.00@sampark.hss.hns.com> Date: Mon, 22 May 2000 16:00:16 +0530 Subject: Re: [SIP] Clarification of CSeq 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com vc > I wonder if the CSeq should not increase its value by one when a session is terminated vc > with the BYE signal? In the draft example the Invite signal has the value CSeq: 1 vc > INVITE and the bye signal CSeq: 1 BYE. Should it not be CSeq: 2 BYE? CSeq numbering is maintained separately in each direction. The sequence nos. from A - B does not relate to the sequence nos. from B-A. so, A had sent an INVITE - and its seq no is 1 B sends a BYE, and hence its seq no can also be 1 (or whatever else). There is no relation b/w the two seq nos. If A sent BYE, then sequence would be 2. vc >Assume that a User A sends 'INVITE' to a User B (CSeq: 1 INVITE). User B replies with vc >'486 busy here' (CSeq: 1 INVITE). What should the value of CSeq be in 'ACK' from User A vc >to User B? I think it should be CSeq: 2 ACK. The value should be the same as the INVITE. ie 1, so as to match the original INVITE-OK transaction to the ACK. (ACK is a new request and its CSeq method param is changed to ACK, the CSeq helps to associate it to the OK response) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Velibor Cakarevic (ECS)" on 05/22/2000 01:40:09 PM To: sip@lists.bell-labs.com cc: Subject: [SIP] Clarification of CSeq In the document draft-ietf-sip-call-flows-00.txt there is an example of a successful SIP to SIP session establishment (chapter 3.1.1). I wonder if the CSeq should not increase its value by one when a session is terminated with the BYE signal? In the draft example the Invite signal has the value CSeq: 1 INVITE and the bye signal CSeq: 1 BYE. Should it not be CSeq: 2 BYE? Assume that a User A sends 'INVITE' to a User B (CSeq: 1 INVITE). User B replies with '486 busy here' (CSeq: 1 INVITE). What should the value of CSeq be in 'ACK' from User A to User B? I think it should be CSeq: 2 ACK. ____________________________________________ Velibor Cakarevic _______________________________________________ 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 May 22 06:54:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28952 for ; Mon, 22 May 2000 06:54:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 913964433E; Mon, 22 May 2000 06:46:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 72F1E44336 for ; Mon, 22 May 2000 06:46:02 -0400 (EDT) Date: Mon, 22 May 2000 12:55:36 +0200 (CEST) From: Lars Berggren To: "Schroeder, Tim" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Comments on Session Timer draft In-Reply-To: <4D45BA2A58A7D3119E050008C7E69E290790CA@trimail2.tri.sbc.com> Message-ID: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Fri, 19 May 2000, Schroeder, Tim wrote: > At any rate, I'd like the draft to address the cases where any of the > UAC/UAS/proxy *require* the session timer feature. I'd consider it OK for > the session to not get set up if the session timer feature weren't supported > by all (or enough) of the UAs, but not OK for the session to get set up > without a timer if one were required anywhere along the path. I agree. I think any sip device involved in the signalling could be interested in a way to: 1) Suggest/request/propose that a timer is used. 2) Require a timer. 3) Kind of inform that resources will be released at a certain time, regardless of whether a session timer is used or not. If no session timer is used you just cant get 100% service. Like "Services applied in this call will time out, send re-INVITE to update the timeout". I think 1 is fulfilled by the current draft. 2 will be so if any of the parties were allowed to add the require header. 3 would be fulfilled if Session-Expires were allowed to be added by a proxy in both requests and responses even if the proxy has no way of knowing whether a timer is supported or not. I cant see the point in disallowing it. Also, again, I think it is sufficient that one of UAS/UAC is session timer aware to keep the session alive. Any comments from the authors? > > Also, the third to the last paragraph in section 4 (beginning "A UAC may use > the refreshing re-INVITE as a normal SIP re-INVITE ...") makes no sense to > me. It talks about sending an *updated* session description and using the > origin field to indicate the description is *unchanged*. > Yes, that subsection confuses me too. Is it a typo? /Lars > Tim Schroeder > tschroeder@tri.sbc.com > SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 08:53:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01344 for ; Mon, 22 May 2000 08:53:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C916444340; Mon, 22 May 2000 08:45:24 -0400 (EDT) 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 2BF0044336 for ; Mon, 22 May 2000 08:45:22 -0400 (EDT) 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 IAA19013; Mon, 22 May 2000 08:52:45 -0400 (EDT) Message-ID: <39292D9D.5685A04@cs.columbia.edu> Date: Mon, 22 May 2000 08:52:45 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Sip Mail List Subject: Re: [SIP] Mime-Version and Content-Language in new Bis References: <00052210383600.29678@gethin> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gethin Liddell wrote: > > Hi, > > can i get confirmation that the mime-version and content-language headers should be present (or not) in the new bis please. > > I remember a thread on the validity of the content-language and thought the result was that it should not exist. I don't think there was such a conclusion. My opinion is that it is an optional header and thus no harm is done nor is complexity increased by including it. It may be useful in some limited circumstances. If information is exported from an HTTP source to a SIP destination, it seems to make sense to avoid losing information when doing the exporting. One slightly less contrived use might be within MIME multiparts, so that a Canadian SIP server could automatically return and label the English and French versions of the HTML or error response (see RFC 1766, Section 3.). MIME-Version again would be optional. I'm not sure if any HTTP servers actually produce this header. As far as I can tell, it's basically a no-op, i.e., it doesn't seem to change behavior in the client or server in any way. I suppose it would matter only if MIME Version 2.0 came along and we wanted to signal this. (Unlike HTTP, SIP obviously does make more extensive use of MIME for multipart bodies.) > > It is still present in the new bis (May) along with the mime-version header but neither are mentioned in Appendix F, have a description of their use or are marked as new. > > thanx > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > gethin@ubiquity.net > > _______________________________________________ > 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 Mon May 22 10:11:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02809 for ; Mon, 22 May 2000 10:10:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E90544343; Mon, 22 May 2000 10:02:48 -0400 (EDT) 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 2335244336 for ; Mon, 22 May 2000 10:02:45 -0400 (EDT) Received: from valin (dwillis5.directlink.net [63.64.250.86]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id UAA03772; Mon, 22 May 2000 20:12:39 -0500 From: "Dean Willis" To: "Cary FitzGerald" Cc: "IETF SIP" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for cein Adelaide) Date: Mon, 22 May 2000 09:09:44 -0500 Message-ID: <002201bfc3f7$61063b40$56fa403f@directlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2919.6600 Importance: Normal In-Reply-To: <39289EA7.D0F727C3@cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA02809 I'm really not trying to propose the "gatekeeper control" here -- the fundaments of that are well-established. What I'm attempting to do is show how knowledge about the state of the network can be made available to SIP UAs without having to have the UA explicitly sharing (and understanding)that knowledge. I'm also somewhat muddlingly trying to consider what sort of knowledge might be available at a relatively low cost (both in network and development terms) and how we might apply that knowledge in a variety of SIP environs. -- Dean > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Cary FitzGerald > Sent: Sunday, May 21, 2000 9:43 PM > To: Dean Willis > Cc: Sinnreich, Henry; IETF SIP > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task > for cein Adelaide) > > > This technique is the moral equivalent of H.323 GK-based > bandwidth management. The results from that set of experiences > leaves the proposition unproven. To my way of thinking, there > are a number of inherent weaknesses in the model (for example, in > your scenario, you won't discover anything about the backbone, > only something about the access routers). On the other hand, you > don't need anything new in SIP itself to build such a proxy, right? > > Cary. > > Dean Willis wrote: > > > Henry wrote: > > > Dean wrote: > > > >The real question is to define a mechanism that allows the > > > >health of the network to be assessed in some sort of > > > >meaningful way so that this knowledge may be made available > to the UAC. > > > > > > The model in actually deals with this problem. > > > Upon failure of the RSVP request, the telephony endpoint can > > > alert the user: > > > "QoS cannot be provided, would you like to proceed with the call". > > > > Perhaps, but I'm trying to find a way to get knowledge about > the state of the backbone network into an edge device WITHOUT using RSVP. > > > > It just occurred to met that this could also be used as a means > of traffic shaping enterprise access to fit within the bounds of > a slightly elastic SLA. > > > > Let's say CorpA has an SLA whereby they are allowed to admit up > to an average of 1Mb/S of expedited traffic across any 10-minute > window, and whatever their port will carry of best-effort. > > > > Here's one possible way: > > > > The access routers feeds class-usage counters periodically > (say, 1 minute intervals) to a network management system. This > NMS then calculates a sliding average for each traffic class. > From the current average, it calculates the maximal steady-state > bandwith allowable over the next ten minutes to stay within the > SLA minus a safety margin. The NMS then divides this number by > the average bandwith requirement of a phone call at this site, > thereby generating a number which is roughly the equivalent of > the number of calls that may be admitted RIGHT NOW without > causing a violation of the SLA to occur. The NMS posts this data > to a proxy, which then decrements this number for each additional > call admitted. When a new estimate comes in, it replaces the > current working number. If the working number drops to zero (or > some low threhold to allow for emergency calls), calls are not > admitted unlesss they appropriately marked "urgent". > > > > I suppose one could do a monte-carlo simulation of this and get > a reasonable feel for the efficacy. > > > > -- > > Dean > > > > Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ© > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Mon May 22 12:14:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04466 for ; Mon, 22 May 2000 12:14:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CE9544355; Mon, 22 May 2000 12:06:06 -0400 (EDT) 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 B21574434C for ; Mon, 22 May 2000 12:06:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 22 12:12:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A7AB544345; Mon, 22 May 2000 11:59:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 7A27044341 for ; Mon, 22 May 2000 11:59:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4EC3052C4; Mon, 22 May 2000 11:59:31 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6553452B6 for ; Mon, 22 May 2000 11:59:28 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 22 11:58:20 EDT 2000 Received: from p-voyageur.issy.cnet.fr ([139.100.0.39]) by dusty; Mon May 22 11:58:19 EDT 2000 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Mon, 22 May 2000 17:58:03 +0200 Message-ID: <98388C05D464D111B61800805F150416014856AC@p-ibis.issy.cnet.fr> From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS To: sip@lists.research.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-info-method-03.txt Date: Mon, 22 May 2000 17:57:54 +0200 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA04466 Hi, What's the current status of this draft: "draft-ietf-sip-info-method-03.txt"? I read there was a Last Call on version 2; and on version 3? Is it soon approved by the IESG? Actually, I think I missed something. Thanks for your help ``` (o o) ----------oOO--(_)-OOo-------------- Jean-Emmanuel CHAPRON FRANCE TELECOM R&D DAC/ARS 38-40 rue du général Leclerc 92794 Issy-les-Moulineaux Cedex 9 - France Tel: +33 1 45 29 64 50 ------------------------------------- > -----Message d'origine----- > De: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Date: lundi 10 avril 2000 13:35 > Cc: sip@lists.research.bell-labs.com > Objet: [SIP] I-D ACTION:draft-ietf-sip-info-method-03.txt > > > 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 : The SIP INFO Method > Author(s) : S. Donovan > Filename : draft-ietf-sip-info-method-03.txt > Pages : 10 > Date : 06-Apr-00 > > This document proposes an extension to the Session Initiation > Protocol (SIP). This extension adds the INFO method to the SIP > protocol. The intent of the INFO method is to allow for the carrying > of session related control information that is generated during a > session. One example of such session control information is ISUP and > ISDN signaling messages used to control telephony call services. > This and other example uses of the INFO method may be standardized in > the future. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-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-info-method-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-info-method-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. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 12:39:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04758 for ; Mon, 22 May 2000 12:39:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6718744348; Mon, 22 May 2000 12:31:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id B133244346 for ; Mon, 22 May 2000 12:31:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22486; Mon, 22 May 2000 10:39:37 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA13932; Mon, 22 May 2000 09:39:32 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA13815; Mon, 22 May 2000 09:39:31 -0700 (PDT) Message-Id: <200005221639.JAA13815@nasnfs.eng.sun.com> Date: Mon, 22 May 2000 09:42:38 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide To: giuseppe.ricagni@italtel.it, mat@cisco.com Cc: mat@cisco.com, sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zu6J9Eyif7ZgwvyPmoYH5Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > > * When the callee is roaming, either you use a standardized database transport protocol or you > > delegate the callee home domain proxy to perform the query, but you have a RTT towards the callee > > home domain. > > Which may effectively be zero. > >> Your solution of having synchronized copies of such database all over the world is > > another interesting enhancement, maybe expensive (pretty sure off-the-shelf solutions are already > > out there) > > It doesn't sound much more interesting than a > localize LDAP cache on the client proxy. There > are other ways to do this as well. And it doesn't > imply synchronized; all that is necessary are caches > with TTL's. > > > o the point I was making was that for all subsequent mid-call messages, just like the INVITEs > > you have to send for handovers, you should shortcut and avoid the round trip to the home > > net. > > I disagree. Most traffic is between the two UA's. > And it absolutely does not follow that proxies > need to have any part in handoffs. In fact, I > do not believe that proxies have any part in > handoffs when the UA is in the mobile unit. > > > * When the caller is roaming, under certain circumstances (related to the type of value added > > services required & the set of services supported by the visited network & the possibility to > > transfer a user profile--see my previous messages) > > I don't know what services the roaming network > wants to provide -- other than trying to shoehorn > themselves into the call. Even if, there is nothing > to prevent me from obtaining those service even if > it's routed through my home proxy first. > What about having a standardized XML-based user profile description? That way, the guy that wants to set up a telephony provider in his garage can have the same access to a description of his services as anybody else. Not that this has anything to do with SIP... jak _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 12:42:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04843 for ; Mon, 22 May 2000 12:42:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A66CD4437D; Mon, 22 May 2000 12:34:05 -0400 (EDT) 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 41A0644377 for ; Mon, 22 May 2000 12:34:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 22 12:40:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id B5E4644344; Mon, 22 May 2000 12:27:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 8C2E744341 for ; Mon, 22 May 2000 12:27:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5D60752C4; Mon, 22 May 2000 12:27:31 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7C04D52AB for ; Mon, 22 May 2000 12:27:28 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 22 12:25:06 EDT 2000 Received: from thumper.research.telcordia.com ([128.96.41.1]) by dusty; Mon May 22 12:25:05 EDT 2000 Received: from research.telcordia.com (shim-pc [192.4.8.82]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e4MGOlg15070; Mon, 22 May 2000 12:24:47 -0400 (EDT) Message-ID: <39295F4F.4227A45@research.telcordia.com> Date: Mon, 22 May 2000 12:24:47 -0400 From: Hyong Sop Shim Organization: Telcordia Technologies X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Multimedia Conferencing using SIP References: <410B13D70EB2D211827E00E0291E9FF7B2BCF4@ORT-MAIL> <39238277.963763CC@dynamicsoft.com> <39258FFF.6D51A10A@research.telcordia.com> <3925A7C3.D1422138@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit In the case of the conferences based on "dial-up" bridges, the current model is that the invited user contacts the dial-up bridge as a result of receving an INVITE message with an Also header sent by an existing conference participant. Instead, why not have the dial-up bridge directly invite the invited user? That is, why not have the existing conference member send the same INVITE with an Also header to the dial-up bridge and have the bridge "relay" the INVITE to the user specified in the Also header? This approach would eliminate the need for the dial-up bridge having to subsume call legs and provide more a means for allerting the invited user of the current membership of the conference than RCTP. Thanks, --Hyong Jonathan Rosenberg wrote: > Hyong Sop Shim wrote: > > > > Jonathan Rosenberg wrote: > > > > > No extensions needed for central conference servers. It works just like > > > it does in the PSTN - you dial a number which corresponds to a port on a > > > bridge. In the case of SIP, you would INVITE to a URL corresponding to a > > > port on the conference server, like sip:conference33287372@mcu.com. The > > > result appears as a point to point SIP call as far as your UA is > > > concerned, but the server is mixing media and sending the mixed media to > > > your UA. You will learn the identity of the other participants through > > > RTCP CSRC. > > > > > > How do you know the right URL to send an INVITE to? Well, how do you > > > know what number to dial for a conference in PSTN? You're told out of > > > band. URLs can be included in emails, web pages, whatever. > > > > > > > In "SIP Call Control Services," the underlying model for establishing a conference seems to be that it is the responsibility of the invited user to send INVITE requests to the existing conference participants. > > That is one model, but not the only one SIP provides. SIP has four ways > to do multiparty conferencing: > > 1. dialup conference bridge: call the bridge just like you call a > person. Conference is identified by request URI. Works with rfc2543 - no > extensions needed. > 2. distributed multiparty conferencing - no server. Fully distributed. > This is what is described in the now-expired draft, and is work in > progress. > 3. multicast conferences - you can run your conference on multicast. > Simply INVITE the person to join the multicast session. Works with > baseline SIP. In fact, this was the initial purpose of SIP. In this > case, there is not a full mesh of SIP signaling. > 4. 3-way with local MC/MP function: A and B are talking. A wishes to add > C to the call. A can simply call C, but also act as a mixer, so that the > media it sends to B contains the A+C media, and the media to C is the > A+B media. RTCP CSRC indicate who is in the conference. This also works > with baseline SIP. It imposes additional burden on the UA, but otherwise > provides this standard feature in a simple way. > > There is no preferred way. It depends on the particular application. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 May 22 15:55:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09163 for ; Mon, 22 May 2000 15:55:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 290564434A; Mon, 22 May 2000 15:47:08 -0400 (EDT) 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 B17E244346 for ; Mon, 22 May 2000 15:47:04 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA27070; Mon, 22 May 2000 12:55:10 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA27349; Mon, 22 May 2000 12:55:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14633.37013.510735.449412@thomasm-u1.cisco.com> Date: Mon, 22 May 2000 12:55:01 -0700 (PDT) To: James Kempf Cc: giuseppe.ricagni@italtel.it, mat@cisco.com, sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <200005221639.JAA13815@nasnfs.eng.sun.com> References: <200005221639.JAA13815@nasnfs.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf writes: > > I don't know what services the roaming network > > wants to provide -- other than trying to shoehorn > > themselves into the call. Even if, there is nothing > > to prevent me from obtaining those service even if > > it's routed through my home proxy first. > > > > > What about having a standardized XML-based user profile description? > That way, the guy that wants to set up a telephony provider in > his garage can have the same access to a description of his > services as anybody else. I think we have arrived at an impasse since I view this as a bug, not a feature. A standardized scheme always locks you to the least common denominator when you want to remote the features. That sounds like a shame to me; if I run it through my home proxy, I can have as many whacko features as I want to cook up without having to convince the world that they're a Good Idea. That way, the market decides rather than a bunch of standards weenies (present company excluded, yadda yadda). Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 16:26:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09468 for ; Mon, 22 May 2000 16:26:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C52EF4433D; Mon, 22 May 2000 16:18:41 -0400 (EDT) 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 38EF044336 for ; Mon, 22 May 2000 16:18:39 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FUZ00801A3TUM@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 22 May 2000 20:26:17 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FUZ0080QA3TSQ@firewall.mcit.com>; Mon, 22 May 2000 20:26:17 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FUZ008019WSRW@pmismtp04.wcomnet.com>; Mon, 22 May 2000 20:22:07 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FUZ008019VFNP@pmismtp04.wcomnet.com>; Mon, 22 May 2000 20:22:03 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FUZ0082I9V08E@pmismtp04.wcomnet.com>; Mon, 22 May 2000 20:21:02 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Mon, 22 May 2000 20:25:07 +0000 Content-return: allowed Date: Mon, 22 May 2000 20:24:55 +0000 From: "Sinnreich, Henry" Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide To: "'Michael Thomas'" Cc: giuseppe.ricagni@italtel.it, sip@lists.bell-labs.com, James Kempf Message-id: <75C79E507864D3118AFC00805FEAB7D85B26D4@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >That way, the market > decides rather than a bunch of standards > weenies Wow Michael! The Internet is defined entirely by its standard protocols, developed with great care by 'weenies', and not by 'market decides' managers. We know a lot of protocols developed by 'market decides' managers that are now history. >> view this as a bug, not a feature. Actually, the portability of the service may seem very attractive to customers, and is one of the SIP potential applications. I could upload my preferences to the convenient service when on travel for example, to reduce some costs. Also, I could change these preferences when on travel, so as to adjust them to my changed needs. Enlightened service providers that allow such conveniences may be preferred by customers. My two cents, Henry >-----Original Message----- >From: Michael Thomas [mailto:mat@cisco.com] >Sent: Monday, May 22, 2000 2:55 PM >To: James Kempf >Cc: giuseppe.ricagni@italtel.it; mat@cisco.com; sip@lists.bell-labs.com >Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide > > >James Kempf writes: > > > I don't know what services the roaming network > > > wants to provide -- other than trying to shoehorn > > > themselves into the call. Even if, there is nothing > > > to prevent me from obtaining those service even if > > > it's routed through my home proxy first. > > > > > > > > > What about having a standardized XML-based user profile description? > > That way, the guy that wants to set up a telephony provider in > > his garage can have the same access to a description of his > > services as anybody else. > > I think we have arrived at an impasse since I > view this as a bug, not a feature. A standardized > scheme always locks you to the least common > denominator when you want to remote the > features. That sounds like a shame to me; if I > run it through my home proxy, I can have as > many whacko features as I want to cook up > without having to convince the world that > they're a Good Idea. That way, the market > decides rather than a bunch of standards > weenies (present company excluded, yadda > yadda). > > Mike > > >_______________________________________________ >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 May 22 16:34:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09558 for ; Mon, 22 May 2000 16:34:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 65EA54436D; Mon, 22 May 2000 16:26:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id A659044352 for ; Mon, 22 May 2000 16:26:11 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25821; Mon, 22 May 2000 14:34:07 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA28905; Mon, 22 May 2000 13:34:05 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA19595; Mon, 22 May 2000 13:34:04 -0700 (PDT) Message-Id: <200005222034.NAA19595@nasnfs.eng.sun.com> Date: Mon, 22 May 2000 13:37:11 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide To: mat@cisco.com, Henry.Sinnreich@WCOM.Com Cc: giuseppe.ricagni@italtel.it, sip@lists.bell-labs.com, James.Kempf@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HnmmRUlCJteaMdCblebiEg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > >>That way, the market >> decides rather than a bunch of standards >> weenies > >Wow Michael! The Internet is defined entirely by its standard protocols, >developed with great care by 'weenies', and not by 'market decides' >managers. We know a lot of protocols developed by 'market decides' managers >that are now history. > >>> view this as a bug, not a feature. >Actually, the portability of the service may seem very attractive to >customers, and is one of the SIP potential applications. I could upload my >preferences to the convenient service when on travel for example, to reduce >some costs. Also, I could change these preferences when on travel, so as to >adjust them to my changed needs. Enlightened service providers that allow >such conveniences may be preferred by customers. > Right. The other thing a standardized user profile format would let me do is edit services on any Web browser rather than have to call up the phone company and wait for them change my service profile. In New World Telephony, this empowers the user so that they effectively control their services. The phone company benefits in that their administrative costs are reduced. And if the XML DTD for the user profile is made extensible, phone service providers can add customized features, just like Web pages have different features. jak >My two cents, Henry > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: Monday, May 22, 2000 2:55 PM >>To: James Kempf >>Cc: giuseppe.ricagni@italtel.it; mat@cisco.com; sip@lists.bell-labs.com >>Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide >> >> >>James Kempf writes: >> > > I don't know what services the roaming network >> > > wants to provide -- other than trying to shoehorn >> > > themselves into the call. Even if, there is nothing >> > > to prevent me from obtaining those service even if >> > > it's routed through my home proxy first. >> > > >> > >> > >> > What about having a standardized XML-based user profile description? >> > That way, the guy that wants to set up a telephony provider in >> > his garage can have the same access to a description of his >> > services as anybody else. >> >> I think we have arrived at an impasse since I >> view this as a bug, not a feature. A standardized >> scheme always locks you to the least common >> denominator when you want to remote the >> features. That sounds like a shame to me; if I >> run it through my home proxy, I can have as >> many whacko features as I want to cook up >> without having to convince the world that >> they're a Good Idea. That way, the market >> decides rather than a bunch of standards >> weenies (present company excluded, yadda >> yadda). >> >> Mike >> >> >>_______________________________________________ >>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 May 22 16:35:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09574 for ; Mon, 22 May 2000 16:35:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6EE8F4437A; Mon, 22 May 2000 16:26:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from witbier.cisco.com (witbier.cisco.com [171.71.152.57]) by lists.bell-labs.com (Postfix) with ESMTP id CAB7944352 for ; Mon, 22 May 2000 16:26:41 -0400 (EDT) Received: from mramalho-nt1 (ssh.cisco.com [171.69.10.34]) by witbier.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA27013; Mon, 22 May 2000 13:34:35 -0700 (PDT) Message-Id: <4.1.20000522162311.00a3ccb0@localhost> X-Sender: mramalho@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 22 May 2000 16:36:19 -0400 To: Michael Thomas , James Kempf From: "Michael A. Ramalho" Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide Cc: giuseppe.ricagni@italtel.it, mat@cisco.com, sip@lists.bell-labs.com In-Reply-To: <14633.37013.510735.449412@thomasm-u1.cisco.com> References: <200005221639.JAA13815@nasnfs.eng.sun.com> <200005221639.JAA13815@nasnfs.eng.sun.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com James/Mike, I, for one, am grateful that you two have realized that this is the crux of the debate between you. Can we go on now? What Mike Thomas says is correct .... the standardized scheme will lock you into some core or least common denominator services. Because the relative scarcity of really neat features in the wireless world ... some architects of tremendously successful wireless deployments (e.g., GSM) believe that their success was in the standardization of profiles. I think they are/were correct from the perspective of billing (and the corresponding roaming agreements) and some traditional "old world" PSTN services. [When once in a vacuum, any particulate matter looks interesting.] However, it is *very* clear to me that in the "new world" of web-based or web-like services (and services definition) that standardization of anything but the most rudimentary subscriber information or core services will not make it in "new world" deployments. Don't fence me in, Michael Ramalho At 12:55 PM 5/22/00 -0700, Michael Thomas wrote: >James Kempf writes: > > > I don't know what services the roaming network > > > wants to provide -- other than trying to shoehorn > > > themselves into the call. Even if, there is nothing > > > to prevent me from obtaining those service even if > > > it's routed through my home proxy first. > > > > > > > > > What about having a standardized XML-based user profile description? > > That way, the guy that wants to set up a telephony provider in > > his garage can have the same access to a description of his > > services as anybody else. > > I think we have arrived at an impasse since I > view this as a bug, not a feature. A standardized > scheme always locks you to the least common > denominator when you want to remote the > features. That sounds like a shame to me; if I > run it through my home proxy, I can have as > many whacko features as I want to cook up > without having to convince the world that > they're a Good Idea. That way, the market > decides rather than a bunch of standards > weenies (present company excluded, yadda > yadda). > > Mike > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > Michael A. Ramalho, Ph.D. Cisco Systems 1802 Rue de la Port Wall Township, NJ 07719-3784 Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.732.449.5762 Cell: +1.732.809.0188 Pager: +1.800.365.4578 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 16:39:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09601 for ; Mon, 22 May 2000 16:39:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E70B44394; Mon, 22 May 2000 16:30:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id F06D044392 for ; Mon, 22 May 2000 16:30:25 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28926; Mon, 22 May 2000 14:38:21 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA29820; Mon, 22 May 2000 13:38:15 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA19715; Mon, 22 May 2000 13:38:15 -0700 (PDT) Message-Id: <200005222038.NAA19715@nasnfs.eng.sun.com> Date: Mon, 22 May 2000 13:41:21 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide To: mat@cisco.com, James.Kempf@eng.sun.com, mramalho@cisco.com Cc: giuseppe.ricagni@italtel.it, mat@cisco.com, sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: I33IWB+7kIBfJf8Cv/SMeA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >However, it is *very* clear to me that in the "new world" >of web-based or web-like services (and services definition) >that standardization of anything but the most rudimentary >subscriber information or core services will not make it in >"new world" deployments. > >Don't fence me in, > Don't see why this should be any more the case for a telephony DTD than for any other standardized XML document. Naturally, there needs to be some provision in the format for extensibility, and I suspect that Old World Telephony GSM standardization didn't see the need for that. jak >Michael Ramalho > >At 12:55 PM 5/22/00 -0700, Michael Thomas wrote: >>James Kempf writes: >> > > I don't know what services the roaming network >> > > wants to provide -- other than trying to shoehorn >> > > themselves into the call. Even if, there is nothing >> > > to prevent me from obtaining those service even if >> > > it's routed through my home proxy first. >> > > >> > >> > >> > What about having a standardized XML-based user profile description? >> > That way, the guy that wants to set up a telephony provider in >> > his garage can have the same access to a description of his >> > services as anybody else. >> >> I think we have arrived at an impasse since I >> view this as a bug, not a feature. A standardized >> scheme always locks you to the least common >> denominator when you want to remote the >> features. That sounds like a shame to me; if I >> run it through my home proxy, I can have as >> many whacko features as I want to cook up >> without having to convince the world that >> they're a Good Idea. That way, the market >> decides rather than a bunch of standards >> weenies (present company excluded, yadda >> yadda). >> >> Mike >> >> >>_______________________________________________ >>SIP mailing list >>SIP@lists.bell-labs.com >>http://lists.bell-labs.com/mailman/listinfo/sip >> > > >Michael A. Ramalho, Ph.D. >Cisco Systems >1802 Rue de la Port >Wall Township, NJ 07719-3784 >Office email: mramalho@cisco.com >Personal email: mar42@cornell.edu >Office: +1.732.449.5762 >Cell: +1.732.809.0188 >Pager: +1.800.365.4578 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 19:59:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11380 for ; Mon, 22 May 2000 19:59:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB3A34433D; Mon, 22 May 2000 19:51:29 -0400 (EDT) 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 17DAD44336 for ; Mon, 22 May 2000 19:51:27 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 22 May 2000 18:59:24 -0500 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L3G7K3DS; Mon, 22 May 2000 19:59:02 -0400 Received: from long-pc.corpwest.baynetworks.com. (LONG-PC [134.177.35.89]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJLBZD92; Mon, 22 May 2000 16:58:59 -0700 Message-Id: <3.0.1.32.20000522165930.01386eb0@zsc4c006.corpwest.baynetworks.com> X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 22 May 2000 16:59:30 -0700 To: sip@lists.bell-labs.com X-Sybari-Space: 00000000 00000000 00000000 From: "Lyndon Ong" Subject: RE: [SIP] SIP ISUP MIME type In-Reply-To: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Folks, Apart from Kevin's comment on explicitly specifying the starting boundary for an encapsulated ISUP message, are there any other comments on draft-ietf-sip-isup-mime-01.txt? Cheers, L. Ong _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 22 22:46:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14325 for ; Mon, 22 May 2000 22:46:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 962C34436C; Mon, 22 May 2000 22:38:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 56AC844336 for ; Mon, 22 May 2000 22:38:31 -0400 (EDT) Received: from dynamicsoft.com (1Cust106.tnt7.bos2.da.uu.net [63.27.144.106]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA04081; Mon, 22 May 2000 22:47:32 -0400 (EDT) Message-ID: <3929F3D0.616FEB5E@dynamicsoft.com> Date: Mon, 22 May 2000 22:58:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf Cc: mat@cisco.com, Henry.Sinnreich@WCOM.Com, giuseppe.ricagni@italtel.it, sip@lists.bell-labs.com Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide References: <200005222034.NAA19595@nasnfs.eng.sun.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf wrote: > > > > >>That way, the market > >> decides rather than a bunch of standards > >> weenies > > > >Wow Michael! The Internet is defined entirely by its standard protocols, > >developed with great care by 'weenies', and not by 'market decides' > >managers. We know a lot of protocols developed by 'market decides' managers > >that are now history. > > > >>> view this as a bug, not a feature. > >Actually, the portability of the service may seem very attractive to > >customers, and is one of the SIP potential applications. I could upload my > >preferences to the convenient service when on travel for example, to reduce > >some costs. Also, I could change these preferences when on travel, so as to > >adjust them to my changed needs. Enlightened service providers that allow > >such conveniences may be preferred by customers. > > > > Right. The other thing a standardized user profile format would let me do is > edit services on any Web browser rather than have to call up the phone company > and wait for them change my service profile. In New World Telephony, > this empowers the user so that they effectively control their services. > The phone company benefits in that their administrative costs are reduced. > And if the XML DTD for the user profile is made extensible, phone > service providers can add customized features, just like Web pages > have different features. There is certainly room for both. CPL is aimed at exactly this kind of service mobility. Its a well specified API, safe to execute in third party application servers, and enables some nice services. However, its very limited. It cannot do many of the exciting new services I think we will see down the road. These services require more complex APIs and custom services that probably won't be portable. So, users can go to their home servers when they want these more advanced services, and they can use anyone to provide these vanilla, portable ones. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 22 23:16:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14533 for ; Mon, 22 May 2000 23:16:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C27D4438C; Mon, 22 May 2000 23:08:03 -0400 (EDT) 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 12C2D44336 for ; Mon, 22 May 2000 23:07:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 22 23:14:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 105D144344; Mon, 22 May 2000 23:01:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E111E44341 for ; Mon, 22 May 2000 23:01:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6F4BB52C4; Mon, 22 May 2000 23:01:34 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A8FFC52AB for ; Mon, 22 May 2000 23:01:31 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 22 23:00:12 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon May 22 23:00:11 EDT 2000 Received: from dynamicsoft.com (1Cust106.tnt7.bos2.da.uu.net [63.27.144.106]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA04106; Mon, 22 May 2000 23:01:28 -0400 (EDT) Message-ID: <3929F71B.1C2D68EF@dynamicsoft.com> Date: Mon, 22 May 2000 23:12:27 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hyong Sop Shim Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] Multimedia Conferencing using SIP References: <410B13D70EB2D211827E00E0291E9FF7B2BCF4@ORT-MAIL> <39238277.963763CC@dynamicsoft.com> <39258FFF.6D51A10A@research.telcordia.com> <3925A7C3.D1422138@dynamicsoft.com> <39295F4F.4227A45@research.telcordia.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hyong Sop Shim wrote: > > In the case of the conferences based on "dial-up" bridges, the current model is that > the invited user contacts the dial-up bridge as a result of receving an INVITE message with an Also header sent by an existing conference participant. Not neccesarily. The most common model for dial-up bridges is that you simply know the conference ID ahead of time, and call in. Just like in the PSTN today. This doesn't require any SIP extensions, Also or anything else. Instead, why not have > the dial-up bridge directly invite the invited user? That is, why not have the existing > conference member send the same INVITE with an Also header to the dial-up bridge > and have the bridge "relay" the INVITE to the user specified in the Also header? > This approach would eliminate the need for the dial-up bridge having to subsume call > legs and provide more a means for allerting the invited user of the current membership > of the conference than RCTP. Either works. One is more of a consultation feature (call the user, then transfer to the bridge), the other is a third party mechanism (call the bridge, transfer to the user). -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 22 23:22:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14575 for ; Mon, 22 May 2000 23:22:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9019D44373; Mon, 22 May 2000 23:14:01 -0400 (EDT) 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 1F46E44365 for ; Mon, 22 May 2000 23:13:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon May 22 23:20:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9918A44345; Mon, 22 May 2000 23:07:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 6B8BD44341 for ; Mon, 22 May 2000 23:07:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 03D4752C4; Mon, 22 May 2000 23:07:34 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3D88652AB for ; Mon, 22 May 2000 23:07:31 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon May 22 23:06:47 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon May 22 23:06:47 EDT 2000 Received: from dynamicsoft.com (1Cust106.tnt7.bos2.da.uu.net [63.27.144.106]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA04119; Mon, 22 May 2000 23:07:55 -0400 (EDT) Message-ID: <3929F897.1AF02AE9@dynamicsoft.com> Date: Mon, 22 May 2000 23:18:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: CHAPRON Jean-Emmanuel FTRD/DAC/ISS Cc: sip@lists.research.bell-labs.com Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-info-method-03.txt References: <98388C05D464D111B61800805F150416014856AC@p-ibis.issy.cnet.fr> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit CHAPRON Jean-Emmanuel FTRD/DAC/ISS wrote: > > Hi, > > What's the current status of this draft: > "draft-ietf-sip-info-method-03.txt"? I was told informally by IESG that it was approved, but I don't think I ever saw the formal announcement yet. > > I read there was a Last Call on version 2; and on version 3? Is it soon > approved by the IESG? THe last call was issued on v2, comments from IESG (very minor ones) were incorporated into v3, which was submitted and approved. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 22 23:52:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15201 for ; Mon, 22 May 2000 23:52:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF54144338; Mon, 22 May 2000 23:43:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4EB3444336 for ; Mon, 22 May 2000 23:43:50 -0400 (EDT) Received: from dynamicsoft.com (1Cust34.tnt8.bos2.da.uu.net [63.27.147.34]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA04165; Mon, 22 May 2000 23:52:38 -0400 (EDT) Message-ID: <392A0318.1FCB8F56@dynamicsoft.com> Date: Tue, 23 May 2000 00:03:36 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Schroeder, Tim" Cc: "'Lars Berggren'" , sip@lists.bell-labs.com Subject: Re: [SIP] Comments on Session Timer draft References: <4D45BA2A58A7D3119E050008C7E69E290790CA@trimail2.tri.sbc.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Schroeder, Tim" wrote: > > The session timer draft (draft-ietf-sip-session-timer-01.txt) as written is > asymmetric, in that it seems to assume that the UAC is more likely to > impolitely abandon the session, and that the proxies and UAS need some way > to recover from that. > > I'd like to see the reverse case addressed as well: where the UAC (or a > proxy) is distrustful of the UAS, and needs some way to clean up if the UAS > impolitely abandons the session. > > I suppose the keep-alive re-INVITES can still be sent by the UAC, and it > will be the lack of a response (rather than the lack of an incoming message) > which informs the UAC and the proxies that the UAS has dropped off. Exactly. Failure of either UAC or UAS is detected with equal ease this way. > > But in regard to the Open Issues list, I think the answer to the second > issue (should we allow the UAS to insert a Require: timer header?) I think you mean UAC. > should be > YES. Just like the UAS can reject a call that won't be set up with a > session timer, the UAC should be able to avoid having a call set up without > a session timer. It would do this by using the "Require: timer" header > rather than the weaker "Supported: timer" header. If the UAS cannot handle > the feature, the call would be rejected, rather than set up without the > (demanded) timer feature. I recall that there was consensus to do this. Its easy enough anyway; you could do it even if the draft didn't explicitly specify it. > > And for the third Open Issue on the list, a proxy should also be able to add > the "Require: timer" header if the UAC merely "supports" but does not > "require" the feature. Just like the proxy can tighten up the timing > requirements by lowering the expiration time, it should be able to tighten > up the requirements by making the feature "required" rather than merely > "supported". Then, if the UAS did not implement that feature, the request > would be denied. [This might take some more thought; it would seem odd to > the UAC for its request to end up denied for lack of a feature it did not > require.] This was discussed during the meeting and on the mailing list prior to the meeting. The consensus was that we would allow this. A UAC implementing session timer (i.e., supported) would need to be prepared to receive a rejection response with code 420 even though it hadn't inserted a Require header. > > Alternatively, maybe there's no support needed in the UAS at all: the > re-INVITES are all sent from the UAC, and the UAS needn't know anything > about the feature to process them. This is similar to what Lars Berggren < > mailto:lars.berggren@intertex.se> > proposes: I recall thinking about this possibility, but decided it was tricky. The other thing the UAS must do that is not mentioend in Lars' mail is reflect the Session-Expires header. If a UAS doesn't support session timer, the response has no Session-Expires header, with the result is that the proxies won't know the actual expiration time. > > >> > For the Session Timer to be applied for a call leg, the specifications in > the draft requires that both the UAC and UAS understand the extension > (See example 8.5). However, since the keep-alive mechanism is achieved by > sending 'standard' re-INVITEs, it is sufficient (and useful) that at least > one of the parties is aware of the Session Timer to accomplish a > keep-alive mechanism. The usefulness of such an approach is for example > when a UAC supports 'timer', a stateful proxy server, SPS, wants to apply > a Session Timer to the call and the UAS doesn't understand the extension. > > Here, the call will be setup without Session Timer even though the SPS > wanted one and the UAC could do the necessary re-inviting. The UAS doesn't > need to know about Session Timers in order to process re-INVITEs properly. > The only thing that forces that the UAS have to be aware of the Session > Timer is the statement in the draft that the UAS SHOULD send BYE if no > re-INVITE has arrived when the session expires. Well, the UAC could do the > sending of the BYE if it does not intend to update the timer. > > So, to solve this problem, I would like to propose that the SPS could add > a Session-Expires header in the response if the SPS knows the UAC supports > 'timer' and the response does not contain a Session-Expires header. > << > > At any rate, I'd like the draft to address the cases where any of the > UAC/UAS/proxy *require* the session timer feature. I'd consider it OK for > the session to not get set up if the session timer feature weren't supported > by all (or enough) of the UAs, but not OK for the session to get set up > without a timer if one were required anywhere along the path. > > Also, the third to the last paragraph in section 4 (beginning "A UAC may use > the refreshing re-INVITE as a normal SIP re-INVITE ...") makes no sense to > me. It talks about sending an *updated* session description and using the > origin field to indicate the description is *unchanged*. Thats an error. Thanks for pointing it out. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 22 23:59:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15226 for ; Mon, 22 May 2000 23:59:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A40944399; Mon, 22 May 2000 23:51:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1E60D44394 for ; Mon, 22 May 2000 23:51:01 -0400 (EDT) Received: from dynamicsoft.com (1Cust34.tnt8.bos2.da.uu.net [63.27.147.34]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA04173; Mon, 22 May 2000 23:59:51 -0400 (EDT) Message-ID: <392A04CA.4E52474C@dynamicsoft.com> Date: Tue, 23 May 2000 00:10:50 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Berggren Cc: "Schroeder, Tim" , sip@lists.bell-labs.com Subject: Re: [SIP] Comments on Session Timer draft References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Lars Berggren wrote: > > On Fri, 19 May 2000, Schroeder, Tim wrote: > > At any rate, I'd like the draft to address the cases where any of the > > UAC/UAS/proxy *require* the session timer feature. I'd consider it OK for > > the session to not get set up if the session timer feature weren't supported > > by all (or enough) of the UAs, but not OK for the session to get set up > > without a timer if one were required anywhere along the path. > > I agree. I think any sip device involved in the signalling could be > interested in a way to: > 1) Suggest/request/propose that a timer is used. > 2) Require a timer. > 3) Kind of inform that resources will be released at a certain > time, regardless of whether a session timer is used or not. If no session > timer is used you just cant get 100% service. Like "Services applied in > this call will time out, send re-INVITE to update the timeout". > > I think 1 is fulfilled by the current draft. 2 will be so if any of > the parties were allowed to add the require header. 3 would be fulfilled > if Session-Expires were allowed to be added by a proxy in both requests > and responses even if the proxy has no way of knowing whether a timer is > supported or not. I cant see the point in disallowing it. But the proxy does have a way of knowing - the Supported header in the request, coupled with reflection of Session-Expires in the response. I see no point in inserting the header if the proxy knows its not understood. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 23 03:33:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28205 for ; Tue, 23 May 2000 03:33:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5CFFE44339; Tue, 23 May 2000 03:25:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id A7D2344336 for ; Tue, 23 May 2000 03:25:40 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Tue, 23 May 2000 08:29:47 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 May 2000 08:29:44 +0100 Message-ID: <61ABD11436FED21192440000F81F3E3603311B26@nwcwi1a.europe.nortel.com> From: "Joshua Moloney" To: "Lyndon Ong" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP ISUP MIME type Date: Tue, 23 May 2000 08:29:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC488.AA916A5A" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFC488.AA916A5A Content-Type: text/plain Only a minor comment suggesting that the Content-Transfer-Encoding header be removed (see thread "[SIP] Comments on draft-ietf-sip-isup-mime-01", dated 10th May). Regards, Josh Moloney Nortel Networks > -----Original Message----- > From: Lyndon Ong [SMTP:long@nortelnetworks.com] > Sent: 23 May 2000 01:00 > To: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP ISUP MIME type > > Folks, > > Apart from Kevin's comment on explicitly specifying the starting boundary > for an encapsulated ISUP message, are there any other comments on > draft-ietf-sip-isup-mime-01.txt? > > Cheers, > > L. Ong > > > ------_=_NextPart_001_01BFC488.AA916A5A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] SIP ISUP MIME type

Only a minor comment = suggesting that the Content-Transfer-Encoding header be removed
(see thread = "[SIP] Comments on draft-ietf-sip-isup-mime-01", dated 10th = May).

Regards,

Josh Moloney
Nortel = Networks

    -----Original Message-----
    From:   Lyndon Ong = [SMTP:long@nortelnetworks.com]
    Sent:   23 May 2000 01:00
    To:     sip@lists.bell-labs.com
    Subject:       = RE: [SIP] SIP ISUP MIME type

    Folks,

    Apart from Kevin's comment on = explicitly specifying the starting boundary
    for an encapsulated ISUP message, are = there any other comments on
    draft-ietf-sip-isup-mime-01.txt? 

    Cheers,

    L. Ong



------_=_NextPart_001_01BFC488.AA916A5A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 04:09:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28419 for ; Tue, 23 May 2000 04:09:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C57D74436A; Tue, 23 May 2000 04:01:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 9062544336 for ; Tue, 23 May 2000 04:01:19 -0400 (EDT) Date: Tue, 23 May 2000 10:11:01 +0200 (CEST) From: Lars Berggren To: Jonathan Rosenberg Cc: "Schroeder, Tim" , sip@lists.bell-labs.com Subject: Re: [SIP] Comments on Session Timer draft In-Reply-To: <392A04CA.4E52474C@dynamicsoft.com> Message-ID: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Tue, 23 May 2000, Jonathan Rosenberg wrote: > Lars Berggren wrote: > > I think 1 is fulfilled by the current draft. 2 will be so if any of > > the parties were allowed to add the require header. 3 would be fulfilled > > if Session-Expires were allowed to be added by a proxy in both requests > > and responses even if the proxy has no way of knowing whether a timer is > > supported or not. I cant see the point in disallowing it. > > But the proxy does have a way of knowing - the Supported header in the > request, coupled with reflection of Session-Expires in the response. I > see no point in inserting the header if the proxy knows its not > understood. > OK, as the current draft is written, yes. But if it was changed according to my proposal which started this thread, no. Assume the draft was changed to state that either the UAC or the UAS handles the sending of re-INVITE and that only one of the parties need to be session timer aware. That is, a timer can be used even if the UAC does not support timer. The party which sends the re-INVITEs is determined by the content of the Supported header, if present. If the UAC claims support for 'timer' it shall do the re-inviting. Otherwise the UAS does it, if it supports it. Now, with this assumptions, when a request without support for 'timer' arrives at a proxy it could add a Session-Expires header and hope for the UAS to support it, but it has no way of knowing for sure. Also, when a response arriving at a proxy without Session-Expires, but the proxy knows the request claimed support for 'timer', it would be very useful if the proxy was allowed to insert a Session-Expires header in the response. Instead of just allowing the proxy to add the header in these special cases, it could be allowed to be added in any situation since it does not break anything. /Lars > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 04:26:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28475 for ; Tue, 23 May 2000 04:26:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62A1044387; Tue, 23 May 2000 04:18:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 367D244384 for ; Tue, 23 May 2000 04:18:38 -0400 (EDT) Date: Tue, 23 May 2000 10:28:20 +0200 (CEST) From: Lars Berggren To: Jonathan Rosenberg Cc: "Schroeder, Tim" , sip@lists.bell-labs.com Subject: Re: [SIP] Comments on Session Timer draft In-Reply-To: <392A0318.1FCB8F56@dynamicsoft.com> Message-ID: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Tue, 23 May 2000, Jonathan Rosenberg wrote: > > > > > Alternatively, maybe there's no support needed in the UAS at all: the > > re-INVITES are all sent from the UAC, and the UAS needn't know anything > > about the feature to process them. This is similar to what Lars Berggren < > > mailto:lars.berggren@intertex.se> > > proposes: > > I recall thinking about this possibility, but decided it was tricky. The > other thing the UAS must do that is not mentioend in Lars' mail is > reflect the Session-Expires header. If a UAS doesn't support session > timer, the response has no Session-Expires header, with the result is > that the proxies won't know the actual expiration time. > Proxies that insist on knowing the actual expiration time can include a 'Require: timer' in the request. For other proxies I suppose the Session-Expires could be added and eventually decremented in the response-path as well. The proxies will know that the expiration time is not greater than the one they saw/added. And if it is needed, the UAC could reflect the actual expiration time in the ACK. It is not tricky. /Lars Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 05:56:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28929 for ; Tue, 23 May 2000 05:56:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D4C2944339; Tue, 23 May 2000 05:48:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27]) by lists.bell-labs.com (Postfix) with SMTP id 1AC1444336 for ; Tue, 23 May 2000 05:48:31 -0400 (EDT) Received: (qmail 4484 invoked from network); 23 May 2000 09:56:34 -0000 Received: from usern035.uk.uudial.com (HELO GK-VAIO.Dial.pipex.com) (193.149.81.68) by smtp.dial.pipex.com with SMTP; 23 May 2000 09:56:34 -0000 Message-Id: <4.3.1.2.20000523093153.00cb2950@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 23 May 2000 09:44:04 +0100 To: James Kempf From: Graham Klyne Cc: mat@cisco.com, mramalho@cisco.com, giuseppe.ricagni@italtel.it, sip@lists.bell-labs.com In-Reply-To: <200005222038.NAA19715@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] Service/subscriber information definitions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 01:41 PM 5/22/00 -0700, James Kempf wrote: > >However, it is *very* clear to me that in the "new world" > >of web-based or web-like services (and services definition) > >that standardization of anything but the most rudimentary > >subscriber information or core services will not make it in > >"new world" deployments. > > > >Don't fence me in, > > > >Don't see why this should be any more the case for a telephony >DTD than for any other standardized XML document. Naturally, >there needs to be some provision in the format for extensibility, [...] There has been much talk over recent months of the Internet's end-to-end architecture, and the way that it allows innovation by any connected party rather than just those that control the core. (I think SIP is just one fruit of this realization.) I think there is a new front emerging over which the tensions between centralized and decentralized control will occur: content formats. How many organizations are stuck with a certain vendor's software because their documents are in the format of that software? Through XML, XML namespaces, RDF and other initiatives, W3C are working on content formats that offer the potential for an end-to-end content architecture, much as IP has provided an end-to-end communication architecture. The key is something that Tim Berners-Lee has called "language mixing". (see http://www.w3.org/DesignIssues/Evolution.html) These ideas are being developed in the context of WWW, but I belive are applicable to other Interbnet applications. In summary: using the right tools, a definition of core information should not be a fence, but a springboard. (In this, I am broadly agreeing with James.) #g ------------ Graham Klyne (GK@ACM.ORG) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 10:49:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04377 for ; Tue, 23 May 2000 10:49:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 51B314433A; Tue, 23 May 2000 10:40:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 1551644336 for ; Tue, 23 May 2000 10:40:54 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA10283; Tue, 23 May 2000 15:47:01 +0100 (BST) Message-ID: <392A9A1A.F21D1B9A@ubiquity.net> Date: Tue, 23 May 2000 15:47:54 +0100 From: Phil Hoffer Organization: Ubiquity Software Corporation X-Mailer: Mozilla 4.7 [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] Forking Proxy Behaviour w.r.t. Multiple 401 & 407 responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, IMHO various sections within the new version of the bis draft should be updated to reflect the changes made to the paragraph dealing with 4xx,5xx response in section 12.4, pg 84. The modification deals with how a forking proxy should handle multiple authentication responses. This modification means that SIP authentication moves further away from the process defined in rfc2617, HTTP Authentication: Basic and Digest Access Authentication. Perhaps section 14.1 in the bis draft should include a list of general differences w.r.t. SIP Authentication. The topics I'd like to see mentioned are: 1) Now possible for user agent to receive challenges from more than 1 realm in a single response. This contradicts last paragraph of section 3.6 in rfc2617. 2) Possible to receive Proxy-Authenticate header in a 401 response. That said, it's not explicitly stated in rfc2617 that a 401 response can't contain a Proxy-Authenticate header. Also other sections of the bis draft need to be updated inline with this change; 1) Table 5, pg 36, add 401 to "where" column for Proxy-Authenticate header. 2) Add note to section 6.31 Proxy Authenticate, discussing use of the header in a 401 response in the forking proxy scenario. What do you think? Regards Phil -- Phil Hoffer Ubiquity Software Corporation Software Developer Ubiquity House Tel: +44 (0) 1633-765600 Langstone Park Fax: +44 (0) 1633-765601 Newport NP18 2LH URL: 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 May 23 10:56:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04487 for ; Tue, 23 May 2000 10:56:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D75C744359; Tue, 23 May 2000 10:47:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by lists.bell-labs.com (Postfix) with ESMTP id 815F344358 for ; Tue, 23 May 2000 10:47:27 -0400 (EDT) Received: from pqm-cons.demon.co.uk ([158.152.93.237] helo=P162U) by finch-post-12.mail.demon.net with smtp (Exim 2.12 #1) id 12uG5h-000Ebr-0C; Tue, 23 May 2000 14:55:29 +0000 From: "Alex Hardisty" To: Cc: "e-tc32-tg17" , "e-tc32-tg14" Subject: RE: [SIP] SIP ISUP MIME type Date: Tue, 23 May 2000 15:56:54 +0100 Message-ID: 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) In-Reply-To: <3.0.1.32.20000522165930.01386eb0@zsc4c006.corpwest.baynetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Lyndon Ong (Nortel) wrote (on the IETF SIP WG mailing list): > ...are there any other comments on draft-ietf-sip-isup-mime-01.txt? To my knowledge the list of QSIG versions is incorrect. At present there are 3 different versions of QSIG. I have listed them below, each followed by my proposed value for the version parameter: - the first European version (1992) : euro - the first International version (1995) : iso - the internationally aligned version (1997): global I assume that it is possible to extend the list in the future if necessary. It would be useful, for example, to be able to define further versions (for example, "globalN" where N is a digit indicating successive versions) should that prove necessary. Note that I am neither stating nor advocating that there will be future versions ... just catering for the possibility!! -- Alex Hardisty PQM Consultants _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 11:10:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04776 for ; Tue, 23 May 2000 11:10:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFBA94439E; Tue, 23 May 2000 11:02:15 -0400 (EDT) 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 9020544394 for ; Tue, 23 May 2000 11:02:13 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FV000201Q3F44@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 23 May 2000 15:09:16 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FV00012KQ3FME@firewall.mcit.com>; Tue, 23 May 2000 15:09:15 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FV000H01Q2JD1@dgismtp03.wcomnet.com>; Tue, 23 May 2000 15:08:43 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FV000H01Q2BBT@dgismtp03.wcomnet.com>; Tue, 23 May 2000 15:08:43 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FV0006Q8Q26RT@dgismtp03.wcomnet.com>; Tue, 23 May 2000 15:08:30 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Tue, 23 May 2000 15:09:02 +0000 Content-return: allowed Date: Tue, 23 May 2000 15:09:00 +0000 From: "Sinnreich, Henry" Subject: RE: [SIP] Service/subscriber information definitions To: "'Graham Klyne'" , James Kempf Cc: mat@cisco.com, mramalho@cisco.com, giuseppe.ricagni@italtel.it, sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D85B26E5@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >There has been much talk over recent months of the Internet's >end-to-end >architecture, and the way that it allows innovation by any >connected party >rather than just those that control the core. Yes, this is a key issue. Maybe we should be aware what is 'fogging the internet': * Firewalls, * NATS * WAP (discussion at 47th IETF plenary) * Web load balancing switching and web caching * Generic "softswitches" with proprietary Call Agent - similar Garden Wall to services like WAP. Would actually appreciate the feelings of the list members on the effects of "soft switches" on Internet Transparency (RFC 2775). Thanks, Henry >-----Original Message----- >From: Graham Klyne [mailto:GK@Dial.pipex.com] >Sent: Tuesday, May 23, 2000 3:44 AM >To: James Kempf >Cc: mat@cisco.com; mramalho@cisco.com; giuseppe.ricagni@italtel.it; >sip@lists.bell-labs.com >Subject: [SIP] Service/subscriber information definitions > > >At 01:41 PM 5/22/00 -0700, James Kempf wrote: > >> >However, it is *very* clear to me that in the "new world" >> >of web-based or web-like services (and services definition) >> >that standardization of anything but the most rudimentary >> >subscriber information or core services will not make it in >> >"new world" deployments. >> > >> >Don't fence me in, >> > >> >>Don't see why this should be any more the case for a telephony >>DTD than for any other standardized XML document. Naturally, >>there needs to be some provision in the format for extensibility, > >[...] > >There has been much talk over recent months of the Internet's >end-to-end >architecture, and the way that it allows innovation by any >connected party >rather than just those that control the core. (I think SIP is >just one >fruit of this realization.) > >I think there is a new front emerging over which the tensions between >centralized and decentralized control will occur: content >formats. How >many organizations are stuck with a certain vendor's software >because their >documents are in the format of that software? Through XML, >XML namespaces, >RDF and other initiatives, W3C are working on content formats >that offer >the potential for an end-to-end content architecture, much as IP has >provided an end-to-end communication architecture. The key is >something >that Tim Berners-Lee has called "language mixing". (see >http://www.w3.org/DesignIssues/Evolution.html) > >These ideas are being developed in the context of WWW, but I >belive are >applicable to other Interbnet applications. > >In summary: using the right tools, a definition of core >information should >not be a fence, but a springboard. (In this, I am broadly >agreeing with >James.) > >#g > > >------------ >Graham Klyne >(GK@ACM.ORG) > > > >_______________________________________________ >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 May 23 11:47:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05404 for ; Tue, 23 May 2000 11:47:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9BE1C44350; Tue, 23 May 2000 11:38:54 -0400 (EDT) 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 D70A144336 for ; Tue, 23 May 2000 11:38:51 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA06572; Tue, 23 May 2000 08:42:03 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA27619; Tue, 23 May 2000 08:41:55 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14634.42691.201391.341539@thomasm-u1.cisco.com> Date: Tue, 23 May 2000 08:41:55 -0700 (PDT) To: James Kempf Cc: mat@cisco.com, Henry.Sinnreich@WCOM.Com, giuseppe.ricagni@italtel.it, sip@lists.bell-labs.com Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide In-Reply-To: <200005222034.NAA19595@nasnfs.eng.sun.com> References: <200005222034.NAA19595@nasnfs.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Kempf writes: > Right. The other thing a standardized user profile format would let me do is > edit services on any Web browser rather than have to call up the phone company > and wait for them change my service profile. In New World Telephony, > this empowers the user so that they effectively control their services. > The phone company benefits in that their administrative costs are reduced. > And if the XML DTD for the user profile is made extensible, phone > service providers can add customized features, just like Web pages > have different features. If you don't have an XML description of a subscriber's record you can't edit it in a web browser? Are you suggesting that Sun's and Oracle have been selling web gear for the last few years no particular reason at all? :-) Seriously, XML descriptions of user data might be nice if they are used wisely (cf Jonathan's comments), but they don't take the place of graphic design, UI's etc, etc. My point, if it's still unclear, is that forcing standardization to be a _prerequisite_ to deploying service is likely to hamstring innovation if multiple service providers need to agree on anything. I have no such third party dependencies when it's just between me and my service provider. It might be nice if and when they got their act together, but I don't want to depend on that for my cool new features. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 11:49:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05420 for ; Tue, 23 May 2000 11:49:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E9FB44439F; Tue, 23 May 2000 11:39:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by lists.bell-labs.com (Postfix) with ESMTP id ECD314437E for ; Tue, 23 May 2000 11:39:00 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Tue, 23 May 2000 11:19:45 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 May 2000 11:19:45 -0400 Message-ID: <63E0DAD7784FD21188310000F80824B30165808A@zmpkdx02.us.nortel.com> From: "Mo Zonoun" To: "'Alex Hardisty'" , sip Cc: e-tc32-tg17 , e-tc32-tg14 Subject: RE: [SIP] SIP ISUP MIME type Date: Tue, 23 May 2000 11:19:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC4CA.522F5F9C" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFC4CA.522F5F9C Content-Type: text/plain; charset="iso-8859-1" Alex, I was under the impression that once ISO standards are developed national variation are withdrawn. Do we really want to encourage each country or region have their own specific version? If that is the case why bother with ISO? Mo Zonoun -----Original Message----- From: Alex Hardisty [mailto:alex.hardisty@pqmconsultants.com] Sent: Tuesday, May 23, 2000 7:57 AM To: sip Cc: e-tc32-tg17; e-tc32-tg14 Subject: RE: [SIP] SIP ISUP MIME type Lyndon Ong (Nortel) wrote (on the IETF SIP WG mailing list): > ...are there any other comments on draft-ietf-sip-isup-mime-01.txt? To my knowledge the list of QSIG versions is incorrect. At present there are 3 different versions of QSIG. I have listed them below, each followed by my proposed value for the version parameter: - the first European version (1992) : euro - the first International version (1995) : iso - the internationally aligned version (1997): global I assume that it is possible to extend the list in the future if necessary. It would be useful, for example, to be able to define further versions (for example, "globalN" where N is a digit indicating successive versions) should that prove necessary. Note that I am neither stating nor advocating that there will be future versions ... just catering for the possibility!! -- Alex Hardisty PQM Consultants _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFC4CA.522F5F9C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SIP ISUP MIME type

Alex, I was under the impression that once ISO = standards are developed national variation are withdrawn. Do we really = want to encourage each country or region have their own specific = version? If that is the case why bother with ISO?

Mo Zonoun

-----Original Message-----
From: Alex Hardisty [mailto:alex.hardisty@pq= mconsultants.com]
Sent: Tuesday, May 23, 2000 7:57 AM
To: sip
Cc: e-tc32-tg17; e-tc32-tg14
Subject: RE: [SIP] SIP ISUP MIME type


Lyndon Ong (Nortel) wrote (on the IETF SIP WG mailing = list):

> ...are there any other comments on = draft-ietf-sip-isup-mime-01.txt?

To my knowledge the list of QSIG versions is = incorrect. At present there are
3 different versions of QSIG. I have listed them = below, each followed by my
proposed value for the version parameter:

- the first European version = (1992)         : euro
- the first International version = (1995)    : iso
- the internationally aligned version (1997): = global

I assume that it is possible to extend the list in = the future if necessary.
It would be useful, for example, to be able to = define further versions (for
example, "globalN" where N is a digit = indicating successive versions) should
that prove necessary. Note that I am neither stating = nor advocating that
there will be future versions ... just catering for = the possibility!!

--
Alex Hardisty
PQM Consultants



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

------_=_NextPart_001_01BFC4CA.522F5F9C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 12:14:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05865 for ; Tue, 23 May 2000 12:14:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF1A54435F; Tue, 23 May 2000 12:05:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id A2B784433A for ; Tue, 23 May 2000 12:05:55 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id LAA21109 for ; Tue, 23 May 2000 11:15:55 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id LAA26944 for ; Tue, 23 May 2000 11:13:30 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 23 May 2000 11:13:30 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790CC@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: sip@lists.bell-labs.com Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide Date: Tue, 23 May 2000 11:13:22 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com James Kempf [mailto:James.Kempf@eng.sun.com] writes: The other thing a standardized user profile format would let me do is edit services on any Web browser rather than have to call up the phone company and wait for them change my service profile. That may be true, but a standardized user profile format certainly isn't required to be able to edit services with a web browser! Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 12:24:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06045 for ; Tue, 23 May 2000 12:24:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24B3E4438C; Tue, 23 May 2000 12:15:46 -0400 (EDT) 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 ABFA044336 for ; Tue, 23 May 2000 12:15:43 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FV000J01TILM7@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 23 May 2000 16:23:09 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FV000J0ITILH3@firewall.mcit.com>; Tue, 23 May 2000 16:23:09 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FV000101THP40@dgismtp03.wcomnet.com>; Tue, 23 May 2000 16:22:37 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FV000001TH3WJ@dgismtp03.wcomnet.com>; Tue, 23 May 2000 16:22:37 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FV000016TGT71@dgismtp03.wcomnet.com>; Tue, 23 May 2000 16:22:05 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Tue, 23 May 2000 16:22:37 +0000 Content-return: allowed Date: Tue, 23 May 2000 16:22:36 +0000 From: "Sinnreich, Henry" Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide To: "'Schroeder, Tim'" , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D85B26EC@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >a standardized user profile format >certainly isn't >required to be able to edit services with a web browser! There may be outsourcing arrangements between service providers or with resellers, where a standard user profile format is beneficial. The customer may be an enterprise with thousands of individual users. If a change is required in the OSS, entering it by hand in a web browser is a scary proposition. This is the reason why I believe the user profile should be machine readable, in standard XML format. Henry >-----Original Message----- >From: Schroeder, Tim [mailto:schroeder@tri.sbc.com] >Sent: Tuesday, May 23, 2000 11:13 AM >To: sip@lists.bell-labs.com >Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide > > >James Kempf [mailto:James.Kempf@eng.sun.com] writes: > The other thing a standardized user profile format would let me do is > edit services on any Web browser rather than have to call >up the phone > company and wait for them change my service profile. > >That may be true, but a standardized user profile format >certainly isn't >required to be able to edit services with a web browser! > >Tim Schroeder >tschroeder@tri.sbc.com >SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 > > >_______________________________________________ >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 May 23 13:22:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06746 for ; Tue, 23 May 2000 13:22:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D588B4433A; Tue, 23 May 2000 13:14:10 -0400 (EDT) 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 0E20F44336 for ; Tue, 23 May 2000 13:14:08 -0400 (EDT) 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 NAA01400; Tue, 23 May 2000 13:20:32 -0400 (EDT) Message-ID: <392ABDE0.896A738B@cs.columbia.edu> Date: Tue, 23 May 2000 13:20:32 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Phil Hoffer Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] Forking Proxy Behaviour w.r.t. Multiple 401 & 407 responses References: <392A9A1A.F21D1B9A@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I've made changes in various places reflecting this discussion. Thanks for the comments. Phil Hoffer wrote: > > Hi, > > IMHO various sections within the new version of the bis draft should > be updated to reflect the changes made to the paragraph dealing > with 4xx,5xx response in section 12.4, pg 84. > > The modification deals with how a forking proxy should handle multiple > authentication responses. > > This modification means that SIP authentication moves further away > from the process defined in rfc2617, HTTP Authentication: Basic and > Digest Access Authentication. > > Perhaps section 14.1 in the bis draft should include a list of > general differences w.r.t. SIP Authentication. > > The topics I'd like to see mentioned are: > > 1) Now possible for user agent to receive challenges from more than > 1 realm in a single response. This contradicts last paragraph of > section 3.6 in rfc2617. > > 2) Possible to receive Proxy-Authenticate header in a 401 response. > > That said, it's not explicitly stated in rfc2617 that a 401 response > can't contain a Proxy-Authenticate header. > > Also other sections of the bis draft need to be updated inline with > this change; > > 1) Table 5, pg 36, add 401 to "where" column for Proxy-Authenticate > header. > > 2) Add note to section 6.31 Proxy Authenticate, discussing use of > the header in a 401 response in the forking proxy scenario. > > What do you think? -- 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 May 23 14:14:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07416 for ; Tue, 23 May 2000 14:14:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2713644358; Tue, 23 May 2000 14:06:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A9C2A44336 for ; Tue, 23 May 2000 14:06:11 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id TAA17512; Tue, 23 May 2000 19:12:26 +0100 (BST) Message-ID: <392ACA09.E7BA731C@ubiquity.net> Date: Tue, 23 May 2000 19:12:25 +0100 From: Neil Deason 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] REGISTER/OPTIONS and Call-ID Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit In the bis draft, 6.12 Call-ID, it says.... "The REGISTER and OPTIONS methods use the Call-ID to unambiguously match requests to responses." In a REGISTER the Call-ID SHOULD remain the same over at least the same reboot cycle. So isn't the CSeq also required to match requests to responses? If not, why MUST registrations with the same Call-ID have increasing CSeq values? The bis draft also isn't explicity clear to me as to what the Call-ID of OPTIONS should be. Should the Call-ID of an OPTIONS be analogous to an INVITE not the special case of a REGISTER? Cheers, Neil. -- Ubiquity Software Corporation 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 May 23 17:22:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09897 for ; Tue, 23 May 2000 17:22:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CE4034433A; Tue, 23 May 2000 17:14:36 -0400 (EDT) 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 4E1D944336 for ; Tue, 23 May 2000 17:14:34 -0400 (EDT) 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 RAA17969; Tue, 23 May 2000 17:19:18 -0400 (EDT) Message-ID: <392AF5D6.A1340886@cs.columbia.edu> Date: Tue, 23 May 2000 17:19:18 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] REGISTER/OPTIONS and Call-ID References: <392ACA09.E7BA731C@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > In the bis draft, 6.12 Call-ID, it says.... > > "The REGISTER and OPTIONS methods use the Call-ID to unambiguously match > requests to responses." > > In a REGISTER the Call-ID SHOULD remain the same over at least the same > reboot cycle. So isn't the CSeq also required to match requests to > responses? If not, why MUST registrations with the same Call-ID have > increasing CSeq values? Added "(together with CSeq)" for clarity. > > The bis draft also isn't explicity clear to me as to what the Call-ID of > OPTIONS should be. Should the Call-ID of an OPTIONS be analogous to an > INVITE not the special case of a REGISTER? Either: "For these [OPTIONS, REGISTER] requests, it makes no difference whether the \header{Call-ID} value matches an existing call or not." -- 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 May 23 17:25:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09948 for ; Tue, 23 May 2000 17:25:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 527044438F; Tue, 23 May 2000 17:17:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 8C5084438A for ; Tue, 23 May 2000 17:17:07 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA25299 for ; Tue, 23 May 2000 16:27:09 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA03667 for ; Tue, 23 May 2000 16:24:41 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 23 May 2000 16:24:41 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790CE@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: sip@lists.bell-labs.com Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP Date: Tue, 23 May 2000 16:24:30 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Mark Watson [mailto:mwatson@nortelnetworks.com] writes: If we have CS(A) --bicc ---CS(B)---sip --- CS(C)---bicc---CS(D) where 'CS' is 'Call Server', for want of a better term, then there are two cases: (i) with the bearer path routed directly between Gateways controlled by CS(A) and CS(D), and (ii) with further 'packet-to-packet' gateways contolled by CS(B) and CS(C) i.e. there are three 'domains' which are physically interworked at both the call and bearer layer. There is some doubt as to whether (i) will be possible at all - this depends on how the support of IP in BICC is defined over the next few months. If it is possible, I think that it should involve maping the bearer control mechanism in BICC to the equivalent in SIP (SDP) so that the call can still work if it terminates on a pure SIP agent. Agreed. If you do this mapping, then you've removed from the BICC information everything which makes it BICC and not ISUP, so you're not carrying BICC inside SIP at all. But just because you map the information from BICC into SIP, doesn't mean it's removed from the BICC message, does it? In the ISUP--SIP--ISUP case, the ISUP information that makes sense to map to SIP (to provide the desired level of interworking) is mapped, but the ISUP message is still passed along in the body to allow for ISUP transparency, in case the call ends up back on an ISUP-signaled network. I'd think the same mechanism would apply to the BICC--SIP--BICC case: map the BICC information that makes sense to SIP (and the bearer stuff to SDP), but pass along the original BICC message in the body. Then if the call terminates in the SIP-signaled network, you've got your interworking (to the level that you coherently mapped the BICC information to SIP/SDP), and if the call is routed through a gateway back to a BICC-signaled network you can still have "BICC transparency". In case (ii), the three domains are completely independent from each other when it comes to setup of the bearer connection. Again, the only information from BICC left to carry over the SIP domain is the ISUP part. I think I'd still want to send the whole BICC message, even if the non-ISUP part will never be used. The gateways provide the interworking functionality between BICC and SIP; there's no need to have them also interwork between BICC and ISUP (even if that's relatively easy) just so I can avoid an application/BICC or application/Q.1901 MIME type. If we were to carry the BICC APM parameter, which contains the Bearer related information, over SIP, we would be inventing a new way of carrying out bearer setup on a SIP call - an alternative to SDP. I do not think we should do this as it would be non-backwards-compatible. In your case (i), interwork the bearer related information to SDP (which will get used if the call terminates in the SIP-signaled network, ignoring the BICC-embedded APM parameter) and leave it in the BICC message as well, passing the whole BICC message along in the body (which will get used if the call is routed back to the BICC-signaled network). In your case (ii), the gateways are going to have to piece together the three media streams end-to-end, a first BICC APM parameter will describe the CS(A)--CS(B) segment, SDP will describe the CS(B)--CS(C) segment, and a second BICC APM parameter will describe the CS(C)--CS(D) segment. I don't think there's much BICC/APM-to-SDP interworking that can be done there, but the BICC message may as well be passed along, rather than first converting it to the ISUP format. Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 17:43:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10202 for ; Tue, 23 May 2000 17:43:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6983D4438D; Tue, 23 May 2000 17:35:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.iitk.ac.in (unknown [210.212.54.10]) by lists.bell-labs.com (Postfix) with ESMTP id 96FBC4437E for ; Tue, 23 May 2000 17:35:00 -0400 (EDT) Received: from qasid.cc.iitk.ac.in (qasid.cc.iitk.ac.in [172.31.1.16]) by mail.iitk.ac.in (8.9.2/8.9.2) with ESMTP id DAA24139 for ; Wed, 24 May 2000 03:14:19 +0530 (IST) Received: from ccpc040.cc.iitk.ac.in (IDENT:skamit@ccpc040.cc.iitk.ac.in [172.31.4.40]) by qasid.cc.iitk.ac.in (8.9.2/8.9.2) with ESMTP id DAA20060 for ; Wed, 24 May 2000 03:09:37 +0530 (IST) Date: Wed, 24 May 2000 03:04:14 +0530 (IST) From: Amit Kumar Singh tr cc X-Sender: skamit@ccpc040.cc.iitk.ac.in To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] want some information Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Dear Sir, I need some technecal information about SIP.How it works,what are the hardware requirments to install sip in my I.I.T. Lab.Sir please give me required information at [skamit@iitk.ac.in] Amit Kumar Singh I.I.T. Kanpur INDIA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 18:35:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12088 for ; Tue, 23 May 2000 18:35:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6985644350; Tue, 23 May 2000 18:27:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id CDD8544336 for ; Tue, 23 May 2000 18:27:08 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA26247 for ; Tue, 23 May 2000 17:37:11 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA05104 for ; Tue, 23 May 2000 17:34:46 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 23 May 2000 17:34:45 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790D1@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: sip@lists.bell-labs.com Subject: RE: [SIP] Comments on Session Timer draft Date: Tue, 23 May 2000 17:34:40 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I was reading some of the old messages commenting on the session timer draft, and there was a long discussion about whether re-INVITE or some other method was the "correct" method to use to refresh the timer. A re-INVITE might set up a session that had fallen down, which was perceived to be good. There were issues with Cseq space (addressed by basing them on a local clock), routes (addressed by proxies adding Record-Route to every request they see, media intolerant of sessions being set up again without being cleanly torn down first, and tags. (I didn't see anything addressing the last two.) I'm wondering, though, why the feature must require any specific method at all. If the user agent wants the behavior of re-INVITE, it could send re-INVITEs to refresh the timer. If it doesn't it could send an INFO. In fact, if it were sending "real" re-INVITES anyway (to adjust the media), there'd be no need to send another one just to refresh the timer. Or if it were sending INFO messages anyway (perhaps to keep track of some billing stuff), there'd be no need to send any sort of re-INVITE or INFO just to refresh the timer. And if the user agent were *receiving* messages of any type from the far end, it would also be able to skip the timer refresh messages. Maybe the draft could say that *any* message (sent or received) would refresh the timer? And if the timer were about to expire, that only then must a message be sent? And it could suggest any of a re-INVITE, or an INFO, or ... -- the exact message type wouldn't matter, only that one was sent or received. Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 23 21:55:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15450 for ; Tue, 23 May 2000 21:55:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4310D4433A; Tue, 23 May 2000 21:47:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ACF4E44336 for ; Tue, 23 May 2000 21:47:38 -0400 (EDT) Received: from dynamicsoft.com (1Cust131.tnt2.boston.ma.da.uu.net [63.25.156.131]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA07810; Tue, 23 May 2000 21:55:35 -0400 (EDT) Message-ID: <392B3930.50A2BEC7@dynamicsoft.com> Date: Tue, 23 May 2000 22:06:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Amit Kumar Singh tr cc Cc: sip@lists.bell-labs.com Subject: Re: [SIP] want some information References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/~hgs/sip Amit Kumar Singh tr cc wrote: > > Dear Sir, > I need some technecal information about SIP.How it works,what are > the hardware requirments to install sip in my I.I.T. Lab.Sir please give > me required information at [skamit@iitk.ac.in] > Amit Kumar Singh > I.I.T. Kanpur > INDIA > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 24 03:15:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00538 for ; Wed, 24 May 2000 03:15:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F8F644341; Wed, 24 May 2000 03:07:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from venus.kdd.co.jp (venus.kdd.co.jp [211.4.169.2]) by lists.bell-labs.com (Postfix) with ESMTP id 2998D44336 for ; Wed, 24 May 2000 03:07:01 -0400 (EDT) Received: by venus.kdd.co.jp; id QAA30978; Wed, 24 May 2000 16:15:06 +0900 (JST) From: Received: from em01sjk.kdd.co.jp (localhost [127.0.0.1]) by jupiter.kdd.co.jp (8.8.8/3.6W) with ESMTP id QAA21704 for ; Wed, 24 May 2000 16:15:04 +0900 (JST) Received: from localhost (root@localhost) by kdd.co.jp (8.8.6) with SMTP id QAA14828 for sip@lists.bell-labs.com; Wed, 24 May 2000 16:15:03 +0900 (JST) X-OpenMail-Hops: 1 Date: Wed, 24 May 2000 16:14:58 +0900 Message-Id: Subject: RE: [SIP] SIP ISUP MIME type MIME-Version: 1.0 To: sip@lists.bell-labs.com 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com L. Ong wrote: >Folks, > >Apart from Kevin's comment on explicitly specifying the starting boundary >for an encapsulated ISUP message, are there any other comments on >draft-ietf-sip-isup-mime-01.txt? > In the Table 1 in 3.1, is it possible to add Japanese ISUP variants on the list? If one of the objectives of "base" parameter is to save the namespace for each local standard body, the base name for the Japanese variants should be designated when SIP-T is applied to Japanese network. I feel it is better to be designated in RFC of ISUP MIME type than in any Japanese local documents. I do not think it is a good idea to list the all variants here and also I know "Table 1 is a partial list". But I feel Japanese variants are major and different enough to be put in the list. If you think it is not a bad idea, I think I can discuss this with the members of TTC, which has the responsibility for the Japanese telecommunications standardization, and tell you what is the adequate base name for Japanese variants. Regards, Takuya Sawada ------ Takuya SAWADA (tu-sawada@kdd.co.jp) Network Development Div. Switcing System Dept. IP telephone Group 2-3-2 Nishishinjuku Shinjuku-ku, Tokyo 163-8003, Japan Tel:+81 3 3347 5663 Fax:+81 3 3347 5826 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 03:21:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00591 for ; Wed, 24 May 2000 03:21:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7FD6944360; Wed, 24 May 2000 03:12:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from venus.kdd.co.jp (venus.kdd.co.jp [211.4.169.2]) by lists.bell-labs.com (Postfix) with ESMTP id 5636A4435D for ; Wed, 24 May 2000 03:12:35 -0400 (EDT) Received: by venus.kdd.co.jp; id QAA23700; Wed, 24 May 2000 16:20:46 +0900 (JST) From: Received: from em01sjk.kdd.co.jp (localhost [127.0.0.1]) by jupiter.kdd.co.jp (8.8.8/3.6W) with ESMTP id QAA30238 for ; Wed, 24 May 2000 16:20:43 +0900 (JST) Received: from localhost (root@localhost) by kdd.co.jp (8.8.6) with SMTP id QAA19156 for sip@lists.bell-labs.com; Wed, 24 May 2000 16:20:33 +0900 (JST) X-OpenMail-Hops: 1 Date: Wed, 24 May 2000 16:20:24 +0900 Message-Id: Subject: RE: [SIP] SIP ISUP MIME type MIME-Version: 1.0 To: sip@lists.bell-labs.com 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com L. Ong wrote: >Folks, > >Apart from Kevin's comment on explicitly specifying the starting boundary >for an encapsulated ISUP message, are there any other comments on >draft-ietf-sip-isup-mime-01.txt? > Regarding 'version' parameter, the last sentence of the first paragraph on page 3 says; "If not specified, the default version is assumed to be ITU-T ISUP 1992". But 'version' parameter is defined as a required parameter in the draft. And also NOTE says "It is mandatory for client to specify the 'version' of the ISUPmessage". So the sentence above is correct? Regarding 'base' parameter, it is an optional parameter. Should we define the default value for 'base' parameter, such as "the default base is assumed to be ITU-T ISUP 1992, that is 'base=itu-t92+'" ? Regards, Takuya Sawada ------ Takuya SAWADA (tu-sawada@kdd.co.jp) Network Development Div. Switcing System Dept. IP telephone Group 2-3-2 Nishishinjuku Shinjuku-ku, Tokyo 163-8003, Japan Tel:+81 3 3347 5663 Fax:+81 3 3347 5826 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 04:36:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01179 for ; Wed, 24 May 2000 04:36:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4BF2C4434E; Wed, 24 May 2000 04:27:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by lists.bell-labs.com (Postfix) with ESMTP id 8D8E644336 for ; Wed, 24 May 2000 04:27:51 -0400 (EDT) Received: from pqm-cons.demon.co.uk ([158.152.93.237] helo=P162U) by anchor-post-30.mail.demon.net with smtp (Exim 2.12 #1) id 12uWe3-000F4D-0U; Wed, 24 May 2000 09:36:03 +0100 From: "Alex Hardisty" To: "Mo Zonoun" , "sip" Cc: "e-tc32-tg17" , "e-tc32-tg14" Subject: RE: [SIP] SIP ISUP MIME type Date: Wed, 24 May 2000 09:37:30 +0100 Message-ID: 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 In-Reply-To: <63E0DAD7784FD21188310000F80824B30165808A@zmpkdx02.us.nortel.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Mo Zonoun wrote: > I was under the impression that once ISO standards are developed > national variation are withdrawn. Do we really want to encourage > each country or region have their own specific version? If that is > the case why bother with ISO? That is true and I wasn't suggesting anything different. From the point of view of transporting QSIG information in SIP messages, however, there are implementations of each of the variants in the field and if it is necessary to indicate the version being transported then this should be done correctly. The current Internet Draft (I-D) lists two variants; neither of which (IMHO) accurately describes the actual situation. Regards -- Alex Hardisty PQM Consultants _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 09:47:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05967 for ; Wed, 24 May 2000 09:47:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0990D44341; Wed, 24 May 2000 09:39:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from crash.netspeak.com (unknown [208.143.140.6]) by lists.bell-labs.com (Postfix) with ESMTP id 6AEEC44337 for ; Wed, 24 May 2000 09:39:24 -0400 (EDT) Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 09:46:36 -0400 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A60B3E90@crash.engineering.netspeak.com> From: Linden deCarmo To: "'Schroeder, Tim'" , sip@lists.bell-labs.com Subject: RE: [SIP] Comments on Session Timer draft Date: Wed, 24 May 2000 09:46:35 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >Maybe the draft could say that *any* message (sent or received) would >refresh the timer? I think this is too open ended. Since it is possible to create user-defined methods, this would imply that a server implementing the session-timer support would have to parse all packets, regardless if it understood the method or not. In addition, how could you return a 501 (Not Implemented) if you were looking for and using a header in the packet? I much prefer standardizing on a specific method. Greatly simplifies the implementation. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 10:15:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06463 for ; Wed, 24 May 2000 10:15:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1EB0E44337; Wed, 24 May 2000 10:07:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6870644336 for ; Wed, 24 May 2000 10:07:06 -0400 (EDT) Received: from dynamicsoft.com ([63.89.18.23]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA08688; Wed, 24 May 2000 10:15:51 -0400 (EDT) Message-ID: <392BE6B1.4007FFAC@dynamicsoft.com> Date: Wed, 24 May 2000 10:26:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Linden deCarmo Cc: "'Schroeder, Tim'" , sip@lists.bell-labs.com Subject: Re: [SIP] Comments on Session Timer draft References: <6C5713970B1FD411ACBE00AA00DCD9A60B3E90@crash.engineering.netspeak.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I agree. Lets keep it simple. There are clear benefits to using re-INVITE, as we have discussed in the past. -Jonathan R. Linden deCarmo wrote: > > >Maybe the draft could say that *any* message (sent or received) > would > >refresh the timer? > > I think this is too open ended. Since it is possible to create user-defined > methods, this would imply that a server implementing the session-timer > support would have to parse all packets, regardless if it understood the > method or not. In addition, how could you return a 501 (Not Implemented) if > you were looking for and using a header in the packet? > > I much prefer standardizing on a specific method. Greatly simplifies the > implementation. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 24 10:46:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06910 for ; Wed, 24 May 2000 10:46:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB0C844344; Wed, 24 May 2000 10:38:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by lists.bell-labs.com (Postfix) with ESMTP id 8669044336 for ; Wed, 24 May 2000 10:38:33 -0400 (EDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id <26GSLLRA>; Wed, 24 May 2000 22:46:48 +0800 Message-ID: <30A14FB41CC5D311854D00508B5EEF0201ED557B@exs23.ex.nus.edu.sg> From: Ge Yu To: sip@lists.bell-labs.com Date: Wed, 24 May 2000 22:46:46 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] RE: about proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hi, all, If a UAC sends out an INVITE, which will tranverse 4 proxy servers until it reaches the callee, the servers provide different services, this is standard method of SIP. There is another approach: UAC sends out an INVITE to the first proxy server, which may be its local proxy, then the proxy acts as a client and sends the different service requests to the other 3 proxy servers. Upon the first server receives the responses, it forwards the INVITE directly to the callee, so the INVITE only need to tranverse ONE proxy. Is that possible? thanks for all reply. Yu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 11:43:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07620 for ; Wed, 24 May 2000 11:43:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8243A4435D; Wed, 24 May 2000 11:34:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id CEC5344336 for ; Wed, 24 May 2000 11:34:42 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA24228; Wed, 24 May 2000 16:40:51 +0100 (BST) Message-ID: <392BF802.68B026E1@ubiquity.net> Date: Wed, 24 May 2000 16:40:50 +0100 From: Neil Deason 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] Options Tags - v.minor change req'd to bis text Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This doesn't effect protocol operation in anyway but Option Tags (Section 4.4) of bis draft reads ... "These tags are used in Require (Section 6.35) and Unsupported (Section 6.44) fields." With the addition of Supported in the bis draft that should now read ... "These tags are used in Require (Section 6.35), Supported (Section 6.41) and Unsupported (Section 6.44) fields." hth, Neil -- Ubiquity Software Corporation 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 May 24 12:10:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08185 for ; Wed, 24 May 2000 12:10:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EFD9B44369; Wed, 24 May 2000 12:01:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 2752B44367 for ; Wed, 24 May 2000 12:01:39 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA03985; Wed, 24 May 2000 17:08:00 +0100 (BST) Message-ID: <392BFE60.8BE09351@ubiquity.net> Date: Wed, 24 May 2000 17:08:00 +0100 From: Neil Deason 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] draft-rosenberg-sip-guidelines-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This draft states that a probing mechanism should be defined to aid backwards compatibility when defining new methods. It describes the mechanism to be used as the UAC adding some header to a standard SIP request. The UAS places some information in the response if it understands this header (and thus the extension-method). Couldn't the OPTIONS method be used to provide such a probing mechanism within the standard SIP framework? The response to an OPTIONS request should include an Allow header entity-field that lists the supported set of headers, including any extension-methods. Cheers, Neil. -- Ubiquity Software Corporation 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 May 24 12:28:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08544 for ; Wed, 24 May 2000 12:28:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 74B8744367; Wed, 24 May 2000 12:20:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id BE39444341 for ; Wed, 24 May 2000 12:19:58 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA5A85; Wed, 24 May 2000 12:28:18 -0400 From: "Dave Oran" To: "Dean Willis" , "Michael Thomas" Cc: "IETF SIP" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) Date: Wed, 24 May 2000 12:28:12 -0400 Keywords: IETF Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <003401bfc1e2$7ccf6700$8927a8c0@spud.softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit If you're using Intserv at the edge the router at the edge of the Diffserv cloud will likely know this and reject the reservation. No need for the proxy to get involved. The car analogy is not a good one because in the case of highways you're already stuck at the bottleneck when you find out you're screwed, as opposed to RSVP when you are essentailly clearing all the dead wrecks out of your way before driving up the highway, ala Mad Max. Positing that a SIP proxy has a better idea what the QoS state of the Diffserv core is than the edge router at the edge of that core is like saying the radio announcer knows more about the tornado than the Twister crew chasing it. If there's a oracle which knows the state of the core it can tell the edges as easily or MORE easily than it can tell an undefined sea of application proxy boxes. Dave. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dean Willis > Sent: Friday, May 19, 2000 6:35 PM > To: Michael Thomas > Cc: IETF SIP > Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task > force in Adelaide) > > > > Ah. The networkstatus-aware proxy is effectively advising the SIP > user of congestion in the DiffServ network. Kind of like those > radio announcers that say "Highway 18 is shut down again -- > please use surface streets or just stay home". > > The real question is to define a mechanism that allows the health > of the network to be assessed in some sort of meaningful way so > that this knowledge may be made available to the UAC. > > -- > Dean > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, May 18, 2000 4:32 PM > > To: Dean Willis > > Cc: IETF SIP; Michael Thomas > > Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force > > in Adelaide) > > > > > > Dean Willis writes: > > > Consider it in an aggregation model, like a donut. The chewy > > outside parts of the donut are controlled by IntServ. Traffic > > leaps across the DiffServ donut-hole only if the heuristic > > process thinks (IE, is reasonably sure) that there is adequate > bandwidth. > > > > OK, but I still don't see what that has to do > > with proxies. That sounds like something an > > edge router would do before it admits diffserv > > traffic into the diffserv core. Proxies are even > > more clueless because they never see the actual > > traffic patterns. > > > > Mike > > Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ© _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 12:38:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08775 for ; Wed, 24 May 2000 12:38:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34AD94437B; Wed, 24 May 2000 12:29:49 -0400 (EDT) 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 B467844371 for ; Wed, 24 May 2000 12:29:46 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 24 12:36:44 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6C34444344; Wed, 24 May 2000 12:23:35 -0400 (EDT) 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 C3B3D44341 for ; Wed, 24 May 2000 12:23:34 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 17:23:33 +0100 Message-ID: <57D6C2C01BD9D111A0BE0000C061C3F4023CAE89@uk0006exch003u.uk.lucent.com> From: "Holland, Peter Michael (Peter)" To: sip@lists.bell-labs.com, "'Schroeder, Tim'" Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP Date: Wed, 24 May 2000 17:23:32 +0100 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Considering Tim Schroeder's response to Mark Watson's mail, it was a little difficult to distinguish between the original, and the response, but concerning these extracts: > In case (ii), the three domains are completely independent from each other > when it comes to setup of the bearer connection. Again, the only > information > from BICC left to carry over the SIP domain is the ISUP part. > > I think I'd still want to send the whole BICC message, even if the > non-ISUP > part will never be used. The gateways provide the interworking > functionality between BICC and SIP; there's no need to have them also > interwork between BICC and ISUP (even if that's relatively easy) just so I > can avoid an application/BICC or application/Q.1901 MIME type. > .... > In your case (ii), the gateways are going to have to piece together the > three media streams end-to-end, a first BICC APM parameter will describe > the > CS(A)--CS(B) segment, SDP will describe the CS(B)--CS(C) segment, and a > second BICC APM parameter will describe the CS(C)--CS(D) segment. I don't > think there's much BICC/APM-to-SDP interworking that can be done there, > but > the BICC message may as well be passed along, rather than first converting > it to the ISUP format. > The way the BICC will support IP bearers has not yet been finalised, but this case (ii) is setting up the bearers leg-by-leg, as in BICC CS1. The following should thus be applicable: The information in a BICC APP parameter is of 2 types: 1. that which relates to this bearer segment. 2. that which relates to the codec negotiation procedure. The first of these is not relevant on a subsequent leg of the call and should not be passed on as it is likely to cause confusion on a subsequent leg. The concern expressed refers to "converting to the ISUP format". I'm not sure what the concern really is, considering that the BICC message format is the same as the ISUP message format, from the message type octet onwards. Pete Holland Lucent Technologies, Malmesbury, UK email: pmholland@lucent.com phone: +44 1666 832423 fax: +44 1666 824515 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 13:25:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09599 for ; Wed, 24 May 2000 13:25:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A07B44363; Wed, 24 May 2000 13:17:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id C80D944336 for ; Wed, 24 May 2000 13:17:05 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id SAA28041; Wed, 24 May 2000 18:23:25 +0100 (BST) Message-ID: <392C100D.3B3B0C19@ubiquity.net> Date: Wed, 24 May 2000 18:23:25 +0100 From: Neil Deason 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] 12.4 Forking Proxy - new bis draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit There was a recent discussion on this list (CANCEL related questions) about the validity of the opening line of Section 12.4 Forking Proxy ... "The server must respond to the request immediately with a 100 (Trying) response." I think the general consensus was that this is too sweeping a statement. In the case of a CANCEL request this doesn't make sense as the Proxy will respond immediately, probably with 200 but possibly 481. It also makes no sense for an ACK. It seems worth repeating the 200ms rule of Section 7.1 here ... "The server must respond to the request immediately with a 100 (Trying) response if it expects to take more than 200ms to obtain a final response." 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 May 24 14:24:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10580 for ; Wed, 24 May 2000 14:24:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C7F244371; Wed, 24 May 2000 14:15:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 753DD44336 for ; Wed, 24 May 2000 14:15:33 -0400 (EDT) Received: from dynamicsoft.com ([63.89.18.23]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA10030; Wed, 24 May 2000 14:24:40 -0400 (EDT) Message-ID: <392C2104.D63257A9@dynamicsoft.com> Date: Wed, 24 May 2000 14:35:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ge Yu Cc: sip@lists.bell-labs.com Subject: Re: [SIP] RE: about proxy References: <30A14FB41CC5D311854D00508B5EEF0201ED557B@exs23.ex.nus.edu.sg> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ge Yu wrote: > > hi, all, > > If a UAC sends out an INVITE, which will tranverse 4 proxy servers until it > reaches the callee, the servers provide different services, this is standard > method of SIP. > > There is another approach: UAC sends out an INVITE to the first proxy > server, which may be its local proxy, then the proxy acts as a client and > sends the different service requests to the other 3 proxy servers. Upon the > first server receives the responses, it forwards the INVITE directly to the > callee, so the INVITE only need to tranverse ONE proxy. I think you are talking about forking, but I'm not certain. SIP allows a proxy to receive one request, and forward more than one request out. IN this case, the local proxy would fork and send three INVITEs. These would hit three separate servers, each of which tries to contact the user. As they receive responses, these responses are forwarded upstream to the forking proxy. The first call acceptance that the forking proxy receives is forwarded upstream towards the caller. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 24 15:53:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11785 for ; Wed, 24 May 2000 15:53:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B34064434D; Wed, 24 May 2000 15:45:16 -0400 (EDT) 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 C913044336 for ; Wed, 24 May 2000 15:45:13 -0400 (EDT) Received: from dynamicsoft.com ([63.89.18.34]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id OAA16035; Wed, 24 May 2000 14:54:57 -0500 Message-ID: <392C331E.9F478D3F@dynamicsoft.com> Date: Wed, 24 May 2000 15:53:02 -0400 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Oran Cc: Dean Willis , Michael Thomas , IETF SIP Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dave Oran wrote: > > If you're using Intserv at the edge the router at the edge of the Diffserv > cloud will likely know this and reject the reservation. No need for the > proxy to get involved. In general, I'm not. The WorldCom net, for example, is TOS-priority from end to end. > > The car analogy is not a good one because in the case of highways you're > already stuck at the bottleneck when you find out you're screwed, as opposed > to RSVP when you are essentailly clearing all the dead wrecks out of your > way before driving up the highway, ala Mad Max. > > Positing that a SIP proxy has a better idea what the QoS state of the > Diffserv core is than the edge router at the edge of that core is like > saying the radio announcer knows more about the tornado than the Twister > crew chasing it. A SIP proxy is in a better position to have a persistent relationship with a network management system which can feed it information about the state of the network than a dynamically romin SIP UA is. So, even though the announceer may not know as much about the tornado as the chaser does, he is in a MUCH better position to share that information with the listening audience. > If there's a oracle which knows the state of the core it can tell the edges > as easily or MORE easily than it can tell an undefined sea of application > proxy boxes. Sure, the edges probably know truckloads of cool stuff. But I have no mechanism for the edges to relay this knowledge to the UAs. -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 16:08:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12012 for ; Wed, 24 May 2000 16:08:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCDE44436B; Wed, 24 May 2000 16:00:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 3B07444336 for ; Wed, 24 May 2000 16:00:27 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA994; Wed, 24 May 2000 16:08:47 -0400 From: "Dave Oran" To: "Dean Willis" Cc: "Michael Thomas" , "IETF SIP" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) Date: Wed, 24 May 2000 16:08:41 -0400 Message-ID: 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) In-Reply-To: <392C331E.9F478D3F@dynamicsoft.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ah. I understand. no RSVP == no explicit admission control. That's the bug. Hijacking SIP proxies to do the job of a bandwidth allocation and admission control signaling protocol is ugly at best. You'd need one of these beasts for every application in the universe - rtsp, quake, you name it. If you build SIP proxies the way some people build web server farms you'll have an entirely different scaling problem, which is 100's of SIP proxies polling a poor overworked network managmeent system trying to figure out what it knows about the state of the core (or better stated, what it knew about the core 5 minutes ago when it last gathered enough measurements to make a guess). Register me as a skeptic. Dave. > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: Wednesday, May 24, 2000 3:53 PM > To: Dave Oran > Cc: Dean Willis; Michael Thomas; IETF SIP > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task > force in Adelaide) > > > > > Dave Oran wrote: > > > > If you're using Intserv at the edge the router at the edge of > the Diffserv > > cloud will likely know this and reject the reservation. No need for the > > proxy to get involved. > > In general, I'm not. The WorldCom net, for example, is TOS-priority from > end to end. > > > > > The car analogy is not a good one because in the case of highways you're > > already stuck at the bottleneck when you find out you're > screwed, as opposed > > to RSVP when you are essentailly clearing all the dead wrecks > out of your > > way before driving up the highway, ala Mad Max. > > > > Positing that a SIP proxy has a better idea what the QoS state of the > > Diffserv core is than the edge router at the edge of that core is like > > saying the radio announcer knows more about the tornado than the Twister > > crew chasing it. > > A SIP proxy is in a better position to have a persistent relationship > with a network management system which can feed it information about the > state of the network than a dynamically romin SIP UA is. So, even though > the announceer may not know as much about the tornado as the chaser > does, he is in a MUCH better position to share that information with the > listening audience. > > > If there's a oracle which knows the state of the core it can > tell the edges > > as easily or MORE easily than it can tell an undefined sea of > application > > proxy boxes. > > Sure, the edges probably know truckloads of cool stuff. > > But I have no mechanism for the edges to relay this knowledge to the > UAs. > > -- > Dean > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 16:57:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12973 for ; Wed, 24 May 2000 16:57:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1A1B44381; Wed, 24 May 2000 16:48:44 -0400 (EDT) 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 4FF9744336 for ; Wed, 24 May 2000 16:48:42 -0400 (EDT) Received: from mo3980r1.ems.att.com ([135.38.12.14]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id QAA13296; Wed, 24 May 2000 16:56:58 -0400 (EDT) Received: from njb140bh1.ems.att.com by mo3980r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id QAA01410; Wed, 24 May 2000 16:51:07 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 16:56:57 -0400 Message-ID: From: "Roy, Radhika R, ALARC" To: Dave Oran , Dean Willis Cc: Michael Thomas , IETF SIP Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for ce in Adelaide) Date: Wed, 24 May 2000 16:56:50 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Dave and Dean: Let me try to understand the issues correctly. A SIP proxy server is an application level entity that deals with the application layer signaling scheme. RSVP, DiffServ, etc are the network layer QOS signaling schemes. So, I believe that it would be better to have a clear separation between the two although there can be an abstraction for interworking between the two layers. The question is: How do we this without creating scalability problems? In this context, let us analyze the following: Should the SIP proxy server do the bandwidth allocation and admission control? It depends what the abstraction of bandwidth and admission control is. In true sense, the admission control to the network based on bandwidth and other performance criteria will fall into the category of the lower network layer entities because the network layer resource allocation will be done by them. Now the challenge is: How can this lower network layer information be abstracted (or coupled) to the application layer SIP proxies that are responsible to set up the call on end-to-end basis between the SIP agents? Did I miss something? Best regards, Radhika R. Roy > -----Original Message----- > From: Dave Oran [SMTP:oran@cisco.com] > Sent: Wednesday, May 24, 2000 4:09 PM > To: Dean Willis > Cc: Michael Thomas; IETF SIP > Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security > task force in Adelaide) > > Ah. I understand. no RSVP == no explicit admission control. > That's the bug. Hijacking SIP proxies to do the job of a bandwidth > allocation and admission control signaling protocol is ugly at best. You'd > need one of these beasts for every application in the universe - rtsp, > quake, you name it. > > If you build SIP proxies the way some people build web server farms you'll > have an entirely different scaling problem, which is 100's of SIP proxies > polling a poor overworked network managmeent system trying to figure out > what it knows about the state of the core (or better stated, what it knew > about the core 5 minutes ago when it last gathered enough measurements to > make a guess). > > Register me as a skeptic. > > Dave. > > > -----Original Message----- > > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > > Sent: Wednesday, May 24, 2000 3:53 PM > > To: Dave Oran > > Cc: Dean Willis; Michael Thomas; IETF SIP > > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task > > force in Adelaide) > > > > > > > > > > Dave Oran wrote: > > > > > > If you're using Intserv at the edge the router at the edge of > > the Diffserv > > > cloud will likely know this and reject the reservation. No need for > the > > > proxy to get involved. > > > > In general, I'm not. The WorldCom net, for example, is TOS-priority from > > end to end. > > > > > > > > The car analogy is not a good one because in the case of highways > you're > > > already stuck at the bottleneck when you find out you're > > screwed, as opposed > > > to RSVP when you are essentailly clearing all the dead wrecks > > out of your > > > way before driving up the highway, ala Mad Max. > > > > > > Positing that a SIP proxy has a better idea what the QoS state of the > > > Diffserv core is than the edge router at the edge of that core is like > > > saying the radio announcer knows more about the tornado than the > Twister > > > crew chasing it. > > > > A SIP proxy is in a better position to have a persistent relationship > > with a network management system which can feed it information about the > > state of the network than a dynamically romin SIP UA is. So, even though > > the announceer may not know as much about the tornado as the chaser > > does, he is in a MUCH better position to share that information with the > > listening audience. > > > > > If there's a oracle which knows the state of the core it can > > tell the edges > > > as easily or MORE easily than it can tell an undefined sea of > > application > > > proxy boxes. > > > > Sure, the edges probably know truckloads of cool stuff. > > > > But I have no mechanism for the edges to relay this knowledge to the > > UAs. > > > > -- > > Dean > > > > > > > > _______________________________________________ > 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 May 24 17:40:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13317 for ; Wed, 24 May 2000 17:40:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9D4E144361; Wed, 24 May 2000 17:32:28 -0400 (EDT) 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 C986B44336 for ; Wed, 24 May 2000 17:32:24 -0400 (EDT) Received: from dynamicsoft.com ([63.89.18.34]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id QAA21273; Wed, 24 May 2000 16:42:32 -0500 Message-ID: <392C4C58.4622ED0D@dynamicsoft.com> Date: Wed, 24 May 2000 17:40:41 -0400 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALARC" Cc: Dave Oran , Michael Thomas , IETF SIP Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Actually, I think I completely failed to make my point. I was not suggesting that the proxy do either bandwidth allocation or admission control. It might make sense in some cases, but that's not what I'm talking about. I'm trying to say that a proxy could be a way to get ADVICE about the state of a core network to devices on the edge -- that it could RECOMMEND that a client not try to traverse the net when there is a low probability of success. In general, I don't expect "controls" to survive hostile users. Especially admission-control proxies that one can just go around. Bad idea, don't go there. Or maybe we need a general "Hey, how's the net doing?" protocol . . . -- Dean "Roy, Radhika R, ALARC" wrote: > > Hi, Dave and Dean: > > Let me try to understand the issues correctly. > > A SIP proxy server is an application level entity that deals with the > application layer signaling scheme. > > RSVP, DiffServ, etc are the network layer QOS signaling schemes. > > So, I believe that it would be better to have a clear separation between the > two although there can be an abstraction for interworking between the two > layers. The question is: How do we this without creating scalability > problems? > > In this context, let us analyze the following: > > Should the SIP proxy server do the bandwidth allocation and admission > control? > > It depends what the abstraction of bandwidth and admission control is. > > In true sense, the admission control to the network based on bandwidth and > other performance criteria will fall into the category of the lower network > layer entities because the network layer resource allocation will be done by > them. > > Now the challenge is: How can this lower network layer information be > abstracted (or coupled) to the application layer SIP proxies that are > responsible to set up the call on end-to-end basis between the SIP agents? > > Did I miss something? > > Best regards, > Radhika R. Roy > > > -----Original Message----- > > From: Dave Oran [SMTP:oran@cisco.com] > > Sent: Wednesday, May 24, 2000 4:09 PM > > To: Dean Willis > > Cc: Michael Thomas; IETF SIP > > Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security > > task force in Adelaide) > > > > Ah. I understand. no RSVP == no explicit admission control. > > That's the bug. Hijacking SIP proxies to do the job of a bandwidth > > allocation and admission control signaling protocol is ugly at best. You'd > > need one of these beasts for every application in the universe - rtsp, > > quake, you name it. > > > > If you build SIP proxies the way some people build web server farms you'll > > have an entirely different scaling problem, which is 100's of SIP proxies > > polling a poor overworked network managmeent system trying to figure out > > what it knows about the state of the core (or better stated, what it knew > > about the core 5 minutes ago when it last gathered enough measurements to > > make a guess). > > > > Register me as a skeptic. > > > > Dave. > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > > > Sent: Wednesday, May 24, 2000 3:53 PM > > > To: Dave Oran > > > Cc: Dean Willis; Michael Thomas; IETF SIP > > > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task > > > force in Adelaide) > > > > > > > > > > > > > > > Dave Oran wrote: > > > > > > > > If you're using Intserv at the edge the router at the edge of > > > the Diffserv > > > > cloud will likely know this and reject the reservation. No need for > > the > > > > proxy to get involved. > > > > > > In general, I'm not. The WorldCom net, for example, is TOS-priority from > > > end to end. > > > > > > > > > > > The car analogy is not a good one because in the case of highways > > you're > > > > already stuck at the bottleneck when you find out you're > > > screwed, as opposed > > > > to RSVP when you are essentailly clearing all the dead wrecks > > > out of your > > > > way before driving up the highway, ala Mad Max. > > > > > > > > Positing that a SIP proxy has a better idea what the QoS state of the > > > > Diffserv core is than the edge router at the edge of that core is like > > > > saying the radio announcer knows more about the tornado than the > > Twister > > > > crew chasing it. > > > > > > A SIP proxy is in a better position to have a persistent relationship > > > with a network management system which can feed it information about the > > > state of the network than a dynamically romin SIP UA is. So, even though > > > the announceer may not know as much about the tornado as the chaser > > > does, he is in a MUCH better position to share that information with the > > > listening audience. > > > > > > > If there's a oracle which knows the state of the core it can > > > tell the edges > > > > as easily or MORE easily than it can tell an undefined sea of > > > application > > > > proxy boxes. > > > > > > Sure, the edges probably know truckloads of cool stuff. > > > > > > But I have no mechanism for the edges to relay this knowledge to the > > > UAs. > > > > > > -- > > > Dean > > > > > > > > > > > > > > _______________________________________________ > > 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 May 24 18:08:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13469 for ; Wed, 24 May 2000 18:08:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C1E24437E; Wed, 24 May 2000 17:59:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 09C4244336 for ; Wed, 24 May 2000 17:59:35 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA09572; Wed, 24 May 2000 17:09:40 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id RAA29043; Wed, 24 May 2000 17:07:16 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 24 May 2000 17:07:16 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790D6@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: "'Holland, Peter Michael (Peter)'" , sip@lists.bell-labs.com, "Schroeder, Tim" Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP Date: Wed, 24 May 2000 17:07:10 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Considering Tim Schroeder's response to Mark Watson's mail, it was > a little difficult to distinguish between the original, and > the response, I hate Outlook. The copy in my "sent items" folder looks beautiful; what went out and came back on the mailing list looked wretched. Sorry. > The way the BICC will support IP bearers has not yet been finalised, but this > case (ii) is setting up the bearers leg-by-leg, as in BICC CS1. The following > should thus be applicable: The information in a BICC APP parameter is of 2 > types: > 1. that which relates to this bearer segment. > 2. that which relates to the codec negotiation procedure. > The first of these is not relevant on a subsequent leg of the call > and should not be passed on as it is likely to cause confusion on a > subsequent leg. I agree that the information of type 1 is not relevant. I'm just a little uncomfortable having the gateway on the BICC-to-SIP side edit out part of the BICC message to keep the SIP network happy. It may edit out part of the BICC message for its own reasons (hiding the details of the source network?) but it shouldn't have to do so just because the SIP network can't encapsulate BICC, but only straight ISUP. I don't know of any reason why it *couldn't* edit it out, it just seems easier to pass along the whole BICC message transparently. The destination BICC network can choose to use the parts it thinks are useful, and to ignore the parts it thinks aren't. In the ISUP case, we send the ISUP message transparently, without editing out the parts known (or suspected) to be useless in the destination network. I like that model, and it seems easy enough to follow for BICC as well. And even if BICC looks a lot like ISUP, and after the useless information has been removed may look exactly like ISUP, it still seems cleaner to transmit the BICC as encapsulated BICC, and label it as such with "application/bicc" or some such, rather than calling it ISUP. > The concern expressed refers to "converting to the ISUP format". I'm not sure > what the concern really is, considering that the BICC message format is the same > as the ISUP message format, from the message type octet onwards. Annex E of the Q.1901 document is all about BICC-to-ISUP interworking. The differences don't seem substantial, but ... If the BICC information is stripped of its BICC-ness and encapsulated as ISUP, will the destination end even be able to tell that it used to be BICC? Could that ever be useful? Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 18:15:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13517 for ; Wed, 24 May 2000 18:15:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 207B444396; Wed, 24 May 2000 18:06:39 -0400 (EDT) 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 50A1A44366 for ; Wed, 24 May 2000 18:06:34 -0400 (EDT) Received: from fokus.gmd.de (shaky [193.175.132.94]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA18468; Thu, 25 May 2000 00:12:43 +0200 (MET DST) Message-ID: <392C5408.42CD09E5@fokus.gmd.de> Date: Thu, 25 May 2000 00:13:28 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Oran Cc: Dean Willis , Michael Thomas , IETF SIP Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dave, In the DiffServ case, I see these policies to control the edge: 0) no control; the edge trusts end-devices absolutely; end-devices will get what they want -> not very secure 1) self-control; the edge manages itself; it uses some heuristics to say which packet deserves which class -> heuristics may fail 2) the edge is polled/controlled explicitly by a) end-devices ->they have some built-in control support, e.g. RSVP mapped to DiffServe at the edge b) proxies on behalf of the end-devices ->works w/o changes to end-devices ->application-awareness may be added on top of the admission control, e.g. a SIP/RTSP/quake proxy will be able to decide that all video streams from head of department will be assigned high priority The question: Is 2b an invalid policy? Is it a useful policy? And what is actually the difference in terms of scalability between i) end-devices trying to control/poll the edge [2a] ii) farm of SIP proxies doing the same on behalf of them (possibly using some kind of aggregation) [2b]? The scalability bottleneck is the edge in both cases, isn't it? Thanks, Jiri Dave Oran wrote: > > Ah. I understand. no RSVP == no explicit admission control. > That's the bug. Hijacking SIP proxies to do the job of a bandwidth > allocation and admission control signaling protocol is ugly at best. You'd > need one of these beasts for every application in the universe - rtsp, > quake, you name it. > > If you build SIP proxies the way some people build web server farms you'll > have an entirely different scaling problem, which is 100's of SIP proxies > polling a poor overworked network managmeent system trying to figure out > what it knows about the state of the core (or better stated, what it knew > about the core 5 minutes ago when it last gathered enough measurements to > make a guess). > > Register me as a skeptic. > > Dave. > > > -----Original Message----- > > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > > Sent: Wednesday, May 24, 2000 3:53 PM > > To: Dave Oran > > Cc: Dean Willis; Michael Thomas; IETF SIP > > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task > > force in Adelaide) > > > > > > > > > > Dave Oran wrote: > > > > > > If you're using Intserv at the edge the router at the edge of > > the Diffserv > > > cloud will likely know this and reject the reservation. No need for the > > > proxy to get involved. > > > > In general, I'm not. The WorldCom net, for example, is TOS-priority from > > end to end. > > > > > > > > The car analogy is not a good one because in the case of highways you're > > > already stuck at the bottleneck when you find out you're > > screwed, as opposed > > > to RSVP when you are essentailly clearing all the dead wrecks > > out of your > > > way before driving up the highway, ala Mad Max. > > > > > > Positing that a SIP proxy has a better idea what the QoS state of the > > > Diffserv core is than the edge router at the edge of that core is like > > > saying the radio announcer knows more about the tornado than the Twister > > > crew chasing it. > > > > A SIP proxy is in a better position to have a persistent relationship > > with a network management system which can feed it information about the > > state of the network than a dynamically romin SIP UA is. So, even though > > the announceer may not know as much about the tornado as the chaser > > does, he is in a MUCH better position to share that information with the > > listening audience. > > > > > If there's a oracle which knows the state of the core it can > > tell the edges > > > as easily or MORE easily than it can tell an undefined sea of > > application > > > proxy boxes. > > > > Sure, the edges probably know truckloads of cool stuff. > > > > But I have no mechanism for the edges to relay this knowledge to the > > UAs. > > > > -- > > Dean > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jiri Kuthan Phone: +49-30-3463 7271 GMD FOKUS Fax : +49-30-3463 8271 Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan -- Curious about Internet Telephony? Check http://www.fokus.gmd.de/glone/projects/ipt today! _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 18:16:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13537 for ; Wed, 24 May 2000 18:16:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3992044395; Wed, 24 May 2000 18:08:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id A077344392 for ; Wed, 24 May 2000 18:08:27 -0400 (EDT) Received: by dnspri.npac.com; id RAA20376; Wed, 24 May 2000 17:16:44 -0500 (CDT) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma020352; Wed, 24 May 00 17:16:25 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 24 May 2000 17:16:05 -0500 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" , vkg@lucent.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL clarification for user parameter Date: Wed, 24 May 2000 17:15:19 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com There are four pieces of information related to a freephone number. The first piece is the dialed 800 number (a service number). The second piece is the translated POTS (a telephone number). The third piece is the network routing number (NRN, a number used for routing in the GSTN) if the telephone number is not used for routing (e.g., due to number portability). The fourth piece is the NP database dip indicator. The example assumes that the dialed 800 number results in a ported telephone number; therefore, NP database dip or process is performed to get the NRN for call routing. Assume that a rn parameter is used to carry the NRN and a di parameter is used to carry the NP database dip indicator. If the TO field carries the dialed 800 number, then tel will carry the translated telephone number, rn will carry the NRN and di will carry the dip indicator. But if tel carries the dialed 800 number, then rn will carry the translated telephone number. This is fine if the telephone number is not ported or before NP database dip is performed. But if the telephone number is a ported number, a NRN will be retrieved and used to route the call. That NRN must be carried in the rn, and di will be included. The problem now is where to carry the translated telephone number when that happens (the assumption is that rn will be used for routing when both tel and rn are present). Can tel be used to carry both the dialed 800 number and the translated telephone number (appear twice)? Jonathan's comparison between subscriber phone number/NRN and domain name/IP address is very close. But there is one difference. In GSTN, the subscriber phone number (a name in the NP environment) may still be needed at the terminating GSTN switch in order to terminate the call. The NRN usually just allow the GSTN to route the call to the terminating switch (one NRN for all the subscriber numbers served by that switch, which is the case in the North America). In some countries, the NRN can point to a specific line card at the switch. But in some other countries, the NRN may just point to the terminating network instead of the terminating switch. For the case where the NRN only points to the terminating network, that network will perform another NP database dip to retrieve a NRN that either points to the terminating switch or to a line card at the terminating switch. So the NRN may be changed while the call is being routed to the terminating switch. No matter what, the NRN is used for call routing. Although NP is limited to be within a country (in the national domain), the numbers to be carried in tel and rn should be international numbers as indicated in many SIP examples. So if someone dialed a U.S. 800 number, it would be carried as 1-800-xxx-xxxx in the SIP (country code=1). If one dials the international freephone number, the number carried in the SIP would be 800-xxx...xxxx (country code=800). Unless the country code can be indicated, international numbers will avoid confusion. I'm open to any suggestions as to how to carry the information in the SIP. They can be generated due to ISUP-SIP interworking or due to the situation that a SIP server needs to retrieve the NRN for a ported number (e.g., PC-to-GSTN call). Since number portability (NP) is part of the basic call processing in countries that support NP, SIP may need to specify the call handling when all or some of the four pieces of information are present in the SIP message. But it is apparent that it is the NRN (rn) that is to be used to select the terminating GW or the next hop SIP server (e.g., TRIP) when it is present. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, May 19, 2000 3:46 PM > To: vkg@lucent.com > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP URL clarification for user paramater > > > > > "Vijay K. Gurbani" wrote: > > > > Jonathan/Henning: > > > > In RFC2543bis, section 2, 2nd last paragraph on page 17, you say: > > > > "The user parameter value "np-queried" indicates that > the user part > > contains a telephone number AND that the number > reflects the result > > of a query to the local number portability database". > > > > However, in Figure 3 on page 18, the BNF for user-param is: > > > > user-param = "user="("phone" | "ip") > > > > Should it be modified to: > > > > user-param = "user="(("phone" | "np-queried") | "ip") > > > > A look at the archives indicate that Jonathan and Marc > Petit-Huguenin > > had a thread on this around May 10, 2000 with Jonathan stating that > > there was no consensus on if this was the right way to do this. Any > > updates? > > > None I've seen. I have no problem with the idea of saying > that some kind > of query has been done, but this particular solution is very > specific to > LNP, and I think there is a bigger picture. > > I would argue that the need for this thing at all arises because the > telephone network uses equivalently formatted numbers to refer to two > things - names and actual routing numbers (i.e., addresses). > Its sort of > like what would have happened if IP addresses and domain > names were the > same in syntax and formatting, such that you couldn't tell > one from the > other without checking with some database. The purpose of LNP is much > like DNS, to translate an abstract name to a real routable > address. Now, > in the world of URLs, the namespace (or abstractly, the address space) > of the content of the URL is defined by the scheme. If we > view "numbers > as names" and "numbers as addresses" as difference "namespaces", the > theoretically correct way to indicate that LNP has been done is by > defining a new URL scheme for the two: > > tel:18005551212 and > rn:17325551212 > > where LNP (or 800 number lookup in this case) is used to translate. > > I am not proposing to do this, since practically speaking, its a pain. > But I'd like something more generic to indicate the namespace that the > number fits into. I don't exactly know what or how to do this. Perhaps > this is really just phone-context, with the context being > "routing-number" once translated? > > -Jonathan R. > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com > vkg@acm.org > > IN Architecture and Internet Software Group > > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, > Rm 1A-418 > > 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 > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Wed May 24 19:31:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14094 for ; Wed, 24 May 2000 19:31:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 75D8644344; Wed, 24 May 2000 19:22:40 -0400 (EDT) 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 F139744336 for ; Wed, 24 May 2000 19:22:37 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FV3008017ZJ6U@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 24 May 2000 23:30:55 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FV300MDU7ZJ0G@firewall.mcit.com>; Wed, 24 May 2000 23:30:55 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FV3003017YLN2@dgismtp03.wcomnet.com>; Wed, 24 May 2000 23:30:21 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FV3003017YHGY@dgismtp03.wcomnet.com>; Wed, 24 May 2000 23:30:21 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FV300CIH7YCF2@dgismtp03.wcomnet.com>; Wed, 24 May 2000 23:30:12 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Wed, 24 May 2000 23:30:45 +0000 Content-return: allowed Date: Wed, 24 May 2000 23:30:43 +0000 From: "Sinnreich, Henry" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for ce in Adelaide) To: "'Roy, Radhika R, ALARC'" , Dave Oran , Dean Willis Cc: Michael Thomas , IETF SIP Message-id: <75C79E507864D3118AFC00805FEAB7D85B2729@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Radhika, We have taken a stab at this in http://ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-01.t xt Let us know what you think of the model in this draft. Your comments will be appreciated. This is a good opportunity to discuss, though under a different title. Such as sip-qos? :-) Henry >-----Original Message----- >From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] >Sent: Wednesday, May 24, 2000 3:57 PM >To: Dave Oran; Dean Willis >Cc: Michael Thomas; IETF SIP >Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task >for ce in Adelaide) > > >Hi, Dave and Dean: > >Let me try to understand the issues correctly. > >A SIP proxy server is an application level entity that deals with the >application layer signaling scheme. > >RSVP, DiffServ, etc are the network layer QOS signaling schemes. > >So, I believe that it would be better to have a clear >separation between the >two although there can be an abstraction for interworking >between the two >layers. The question is: How do we this without creating scalability >problems? > >In this context, let us analyze the following: > >Should the SIP proxy server do the bandwidth allocation and admission >control? > >It depends what the abstraction of bandwidth and admission control is. > >In true sense, the admission control to the network based on >bandwidth and >other performance criteria will fall into the category of the >lower network >layer entities because the network layer resource allocation >will be done by >them. > >Now the challenge is: How can this lower network layer information be >abstracted (or coupled) to the application layer SIP proxies that are >responsible to set up the call on end-to-end basis between the >SIP agents? > >Did I miss something? > >Best regards, >Radhika R. Roy > >> -----Original Message----- >> From: Dave Oran [SMTP:oran@cisco.com] >> Sent: Wednesday, May 24, 2000 4:09 PM >> To: Dean Willis >> Cc: Michael Thomas; IETF SIP >> Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security >> task force in Adelaide) >> >> Ah. I understand. no RSVP == no explicit admission control. >> That's the bug. Hijacking SIP proxies to do the job of a bandwidth >> allocation and admission control signaling protocol is ugly >at best. You'd >> need one of these beasts for every application in the >universe - rtsp, >> quake, you name it. >> >> If you build SIP proxies the way some people build web >server farms you'll >> have an entirely different scaling problem, which is 100's >of SIP proxies >> polling a poor overworked network managmeent system trying >to figure out >> what it knows about the state of the core (or better stated, >what it knew >> about the core 5 minutes ago when it last gathered enough >measurements to >> make a guess). >> >> Register me as a skeptic. >> >> Dave. >> >> > -----Original Message----- >> > From: Dean Willis [mailto:dwillis@dynamicsoft.com] >> > Sent: Wednesday, May 24, 2000 3:53 PM >> > To: Dave Oran >> > Cc: Dean Willis; Michael Thomas; IETF SIP >> > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP >Security task >> > force in Adelaide) >> > >> > >> > >> > >> > Dave Oran wrote: >> > > >> > > If you're using Intserv at the edge the router at the edge of >> > the Diffserv >> > > cloud will likely know this and reject the reservation. >No need for >> the >> > > proxy to get involved. >> > >> > In general, I'm not. The WorldCom net, for example, is >TOS-priority from >> > end to end. >> > >> > > >> > > The car analogy is not a good one because in the case of highways >> you're >> > > already stuck at the bottleneck when you find out you're >> > screwed, as opposed >> > > to RSVP when you are essentailly clearing all the dead wrecks >> > out of your >> > > way before driving up the highway, ala Mad Max. >> > > >> > > Positing that a SIP proxy has a better idea what the QoS >state of the >> > > Diffserv core is than the edge router at the edge of >that core is like >> > > saying the radio announcer knows more about the tornado than the >> Twister >> > > crew chasing it. >> > >> > A SIP proxy is in a better position to have a persistent >relationship >> > with a network management system which can feed it >information about the >> > state of the network than a dynamically romin SIP UA is. >So, even though >> > the announceer may not know as much about the tornado as the chaser >> > does, he is in a MUCH better position to share that >information with the >> > listening audience. >> > >> > > If there's a oracle which knows the state of the core it can >> > tell the edges >> > > as easily or MORE easily than it can tell an undefined sea of >> > application >> > > proxy boxes. >> > >> > Sure, the edges probably know truckloads of cool stuff. >> > >> > But I have no mechanism for the edges to relay this >knowledge to the >> > UAs. >> > >> > -- >> > Dean >> > >> > >> >> >> >> _______________________________________________ >> 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 May 24 19:42:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14237 for ; Wed, 24 May 2000 19:42:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1384E44378; Wed, 24 May 2000 19:34:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 636F344372 for ; Wed, 24 May 2000 19:33:58 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA21EA; Wed, 24 May 2000 19:42:20 -0400 From: "Dave Oran" To: "Dean Willis" , "Roy, Radhika R, ALARC" Cc: "Michael Thomas" , "IETF SIP" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) Date: Wed, 24 May 2000 19:42:13 -0400 Keywords: IETF Message-ID: 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) In-Reply-To: <392C4C58.4622ED0D@dynamicsoft.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Or maybe we need a general "Hey, how's the net doing?" protocol . . . > Ping? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 19:48:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14296 for ; Wed, 24 May 2000 19:48:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D1A244385; Wed, 24 May 2000 19:39:48 -0400 (EDT) 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 80AA14437E for ; Wed, 24 May 2000 19:39:45 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FV300F018S3XC@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 24 May 2000 23:48:03 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FV3006688S2EQ@firewall.mcit.com>; Wed, 24 May 2000 23:48:02 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FV3005018L7E3@pmismtp04.wcomnet.com>; Wed, 24 May 2000 23:43:55 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FV3005018L389@pmismtp04.wcomnet.com>; Wed, 24 May 2000 23:43:55 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FV300DI58KV95@pmismtp04.wcomnet.com>; Wed, 24 May 2000 23:43:43 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Wed, 24 May 2000 23:47:50 +0000 Content-return: allowed Date: Wed, 24 May 2000 23:47:49 +0000 From: "Sinnreich, Henry" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for ce in Adelaide) To: "'Dave Oran'" , Dean Willis , Michael Thomas Cc: IETF SIP Message-id: <75C79E507864D3118AFC00805FEAB7D85B272B@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA14296 Agree Dave, Our model has the edge router doing the RSVP aggregation to DiffServ and also knowing the sum of all QoS streams. It is up to the policy server and bandwidth manager to authorize any new application requesting QoS, SIP in this case. The authorization depends on: - the clearinghouse AAA, - the SLS with the backbone, - available BW in the local domain. Henry >-----Original Message----- >From: Dave Oran [mailto:oran@cisco.com] >Sent: Wednesday, May 24, 2000 11:28 AM >To: Dean Willis; Michael Thomas >Cc: IETF SIP >Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task >force in Adelaide) > > >If you're using Intserv at the edge the router at the edge of >the Diffserv >cloud will likely know this and reject the reservation. No need for the >proxy to get involved. > >The car analogy is not a good one because in the case of >highways you're >already stuck at the bottleneck when you find out you're >screwed, as opposed >to RSVP when you are essentailly clearing all the dead wrecks >out of your >way before driving up the highway, ala Mad Max. > >Positing that a SIP proxy has a better idea what the QoS state of the >Diffserv core is than the edge router at the edge of that core is like >saying the radio announcer knows more about the tornado than >the Twister >crew chasing it. > >If there's a oracle which knows the state of the core it can >tell the edges >as easily or MORE easily than it can tell an undefined sea of >application >proxy boxes. > >Dave. > >> -----Original Message----- >> From: sip-admin@lists.bell-labs.com >> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dean Willis >> Sent: Friday, May 19, 2000 6:35 PM >> To: Michael Thomas >> Cc: IETF SIP >> Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP >Security task >> force in Adelaide) >> >> >> >> Ah. The networkstatus-aware proxy is effectively advising the SIP >> user of congestion in the DiffServ network. Kind of like those >> radio announcers that say "Highway 18 is shut down again -- >> please use surface streets or just stay home". >> >> The real question is to define a mechanism that allows the health >> of the network to be assessed in some sort of meaningful way so >> that this knowledge may be made available to the UAC. >> >> -- >> Dean >> >> >> >> > -----Original Message----- >> > From: Michael Thomas [mailto:mat@cisco.com] >> > Sent: Thursday, May 18, 2000 4:32 PM >> > To: Dean Willis >> > Cc: IETF SIP; Michael Thomas >> > Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP >Security task force >> > in Adelaide) >> > >> > >> > Dean Willis writes: >> > > Consider it in an aggregation model, like a donut. The chewy >> > outside parts of the donut are controlled by IntServ. Traffic >> > leaps across the DiffServ donut-hole only if the heuristic >> > process thinks (IE, is reasonably sure) that there is adequate >> bandwidth. >> > >> > OK, but I still don't see what that has to do >> > with proxies. That sounds like something an >> > edge router would do before it admits diffserv >> > traffic into the diffserv core. Proxies are even >> > more clueless because they never see the actual >> > traffic patterns. >> > >> > Mike >> > Hfæj)bz b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿(tm)¨¥(tm)©ÿ-+-SwèþÈ© > > > >_______________________________________________ >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 May 24 22:15:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16451 for ; Wed, 24 May 2000 22:15:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7569144366; Wed, 24 May 2000 22:06:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from public8.sta.net.cn (public8.sta.net.cn [202.96.199.68]) by lists.bell-labs.com (Postfix) with ESMTP id 0809B44336 for ; Wed, 24 May 2000 22:06:37 -0400 (EDT) Received: from unspecified.host (branch-1-n87.sta.net.cn [61.129.25.87]) by public8.sta.net.cn (8.9.3/8.9.3) with SMTP id KAA27136 for ; Thu, 25 May 2000 10:14:47 +0800 (CST) Received: from 10.1.1.20 ([10.1.1.20]) by 10.1.1.200 (WinRoute Pro 4.1) with SMTP; Wed, 24 May 2000 18:08:04 +0800 Message-ID: <003301bfc568$3eb9d520$1401010a@dengpinghong.ulsdc> From: "Deng PingHong - ThatWeb" To: Date: Wed, 24 May 2000 18:10:10 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01BFC5AB.4CC32480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0030_01BFC5AB.4CC32480 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Xu Kun--Thatweb -------------------------------------------------------------------------= --------------------------------------------- Enter ThatWeb http://www.thatweb.com to retrieve your emails anytime, = anywhere ------=_NextPart_000_0030_01BFC5AB.4CC32480 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
Xu=20 Kun--Thatweb
---------------------------------------------------------= -------------------------------------------------------------
Enter=20 ThatWeb http://www.thatweb.com to = retrieve=20 your emails anytime, anywhere
------=_NextPart_000_0030_01BFC5AB.4CC32480-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 24 23:22:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17771 for ; Wed, 24 May 2000 23:22:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7CBD04435B; Wed, 24 May 2000 23:13:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by lists.bell-labs.com (Postfix) with ESMTP id 5CDF544336 for ; Wed, 24 May 2000 23:13:34 -0400 (EDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id <26GSLPC6>; Thu, 25 May 2000 11:21:50 +0800 Message-ID: <30A14FB41CC5D311854D00508B5EEF0201ED557C@exs23.ex.nus.edu.sg> From: Ge Yu To: "'Jonathan Rosenberg '" , Ge Yu Cc: "'sip@lists.bell-labs.com '" Subject: RE: [SIP] RE: about proxy Date: Thu, 25 May 2000 11:21:44 +0800 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hi, Jonathan, Thanks for your fast reply. Actually it can be shown as following: The SIP original operation: (1) (2) (3) (4) (5) (caller)UAC--->proxy1--->proxy2--->proxy3--->proxy4--->UAS(callee) Different proxy provides different service, the services are provided sequentialy, all the (1),(2),(3),(4),(5) are standard SIP INVITE messages. And another scheme: proxy2 proxy3 proxy4 (2)\ (3)/ (4)/ (caller)UAC---->(local)proxy1---->UAS(callee) (1) (5) Now the services of proxy2, proxy3, proxy4 can be provided parallelly. The (1),(5) are still standard SIP INVITE messages. But the (2),(3),(4) are simplified requests which only include the service provided by individual proxy, so (2),(3),(4) messages are different and only part of original INVITE. Proxy1 sends out 3 requests simultaneously, after it gets the 3 reponses from 3 proxies, it rewrite the original INVITE and sends it to UAS. By primarily consideration, the scheme can reduce call setup time, but is it possible in SIP? thanks Yu -----Original Message----- From: Jonathan Rosenberg To: Ge Yu Cc: sip@lists.bell-labs.com Sent: 5/25/00 2:35 AM Subject: Re: [SIP] RE: about proxy Ge Yu wrote: > > hi, all, > > If a UAC sends out an INVITE, which will tranverse 4 proxy servers until it > reaches the callee, the servers provide different services, this is standard > method of SIP. > > There is another approach: UAC sends out an INVITE to the first proxy > server, which may be its local proxy, then the proxy acts as a client and > sends the different service requests to the other 3 proxy servers. Upon the > first server receives the responses, it forwards the INVITE directly to the > callee, so the INVITE only need to tranverse ONE proxy. I think you are talking about forking, but I'm not certain. SIP allows a proxy to receive one request, and forward more than one request out. IN this case, the local proxy would fork and send three INVITEs. These would hit three separate servers, each of which tries to contact the user. As they receive responses, these responses are forwarded upstream to the forking proxy. The first call acceptance that the forking proxy receives is forwarded upstream towards the caller. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Thu May 25 04:14:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01818 for ; Thu, 25 May 2000 04:14:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6715E44353; Thu, 25 May 2000 04:05:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 9221044336 for ; Thu, 25 May 2000 04:05:25 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA14171; Thu, 25 May 2000 09:11:25 +0100 (BST) Message-ID: <392CE02E.3AC6CD48@ubiquity.net> Date: Thu, 25 May 2000 09:11:26 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ge Yu Cc: "'sip@lists.bell-labs.com '" Subject: Re: [SIP] RE: about proxy References: <30A14FB41CC5D311854D00508B5EEF0201ED557C@exs23.ex.nus.edu.sg> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ge Yu wrote: > hi, Jonathan, > > Thanks for your fast reply. > > Actually it can be shown as following: > > The SIP original operation: > > (1) (2) (3) (4) (5) > (caller)UAC--->proxy1--->proxy2--->proxy3--->proxy4--->UAS(callee) > > Different proxy provides different service, the services are provided > sequentialy, all the (1),(2),(3),(4),(5) are standard SIP INVITE messages. > > And another scheme: > proxy2 proxy3 proxy4 > (2)\ (3)/ (4)/ > (caller)UAC---->(local)proxy1---->UAS(callee) > (1) (5) > > Now the services of proxy2, proxy3, proxy4 can be provided parallelly. The > (1),(5) > are still standard SIP INVITE messages. But the (2),(3),(4) are simplified > requests which > only include the service provided by individual proxy, so (2),(3),(4) > messages are different > and only part of original INVITE. Proxy1 sends out 3 requests > simultaneously, after it gets > the 3 reponses from 3 proxies, it rewrite the original INVITE and sends it > to UAS. In the first example the service being performed by the SIP proxies is trying to locate the callee, by routing the INVITE on to the next appropriate hop. What are the services of P2, P3, P4 in your second example? Whatever they are I think describing nodes 2,3,4 as SIP Proxy Servers is leading to confusion. However, if they are SIP nodes offering services, that fall within the solution space of SIP, it might be possible to add a new SIP request method to do what you are describing. hth, 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 Thu May 25 05:45:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02493 for ; Thu, 25 May 2000 05:45:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5BBC4435B; Thu, 25 May 2000 05:37:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id 7B98F44336 for ; Thu, 25 May 2000 05:37:10 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA02806 for ; Thu, 25 May 2000 10:36:10 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA25866 for ; Thu, 25 May 2000 11:45:11 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id LAA05219 for ; Thu, 25 May 2000 11:45:08 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.33]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id LAA00562 for ; Thu, 25 May 2000 11:45:05 +0200 (MET DST) Message-ID: <392CF5FC.E49FAF7F@ms.alcatel.fr> Date: Thu, 25 May 2000 11:44:28 +0200 From: Alberto Conte Reply-To: Alberto.Conte@ms.alcatel.fr Organization: Alcatel - Corporate Research Center X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: it,en,fr MIME-Version: 1.0 To: IETF SIP Subject: [SIP] INVITE with incomplete SDP description References: <75C79E507864D3118AFC00805FEAB7D85B272B@ripexch001.mcit.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit All, I would like to allow a user to send an INVITE message carrying an incomplete session description specifying the list of media types to be used in the session without indicating the RTP ports and addresses for receiving them. That should be useful in case of third-party control, or gateway between two signalling protocols. I thought to something like this: v=0 o=Alberto 2890844730 2890844730 IN IP4 100.101.102.103 s=Hello! t=0 0 m=audio 0 RTP/AVP 3 a=rtpmap:3 GSM/8000 m=video 0 RTP/AVP 32 a=rtpmap:32 MPV/90000 i.e. putting the port number to zero. Is it possible? Can be detailed in the next RFC? Thanks in advance fo the help, Alberto _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 25 06:16:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02641 for ; Thu, 25 May 2000 06:16:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2532144390; Thu, 25 May 2000 06:07:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 9A8FA44336 for ; Thu, 25 May 2000 06:07:09 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA24455; Thu, 25 May 2000 11:13:12 +0100 (BST) Message-ID: <392CFCB8.3B21640@ubiquity.net> Date: Thu, 25 May 2000 11:13:12 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: <75C79E507864D3118AFC00805FEAB7D85B272B@ripexch001.mcit.com> <392CF5FC.E49FAF7F@ms.alcatel.fr> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Alberto Conte wrote: > All, > > I would like to allow a user to send an INVITE message carrying an incomplete session > description specifying the list of media types to be used in the session without > indicating the RTP ports and addresses for receiving them. > > That should be useful in case of third-party control, or gateway between two > signalling protocols. > > I thought to something like this: > > v=0 > o=Alberto 2890844730 2890844730 IN IP4 100.101.102.103 > s=Hello! > t=0 0 > m=audio 0 RTP/AVP 3 > a=rtpmap:3 GSM/8000 > m=video 0 RTP/AVP 32 > a=rtpmap:32 MPV/90000 > > i.e. putting the port number to zero. > > Is it possible? Can be detailed in the next RFC? It already is used to infer a very different meaning from a callee to a caller. Look at Appendix B - Usage of SDP ... "If the callee wants neither to send nor receive a stream offered by the caller, the callee sets the port number of that stream to zero in its media stream." 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 Thu May 25 06:38:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03010 for ; Thu, 25 May 2000 06:38:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCFCE443A5; Thu, 25 May 2000 06:30:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by lists.bell-labs.com (Postfix) with ESMTP id 2A7A544336 for ; Thu, 25 May 2000 06:30:23 -0400 (EDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id <26GSLZNX>; Thu, 25 May 2000 18:38:45 +0800 Message-ID: <30A14FB41CC5D311854D00508B5EEF0201ED557D@exs23.ex.nus.edu.sg> From: Ge Yu To: Ge Yu , "'Neil Deason'" Cc: "'sip@lists.bell-labs.com '" Subject: RE: [SIP] RE: about proxy Date: Thu, 25 May 2000 18:38:39 +0800 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com thanks, Neil, 1. About locate the callee, can we configure the location service as follows: Maintain two kinds of location servers: global location server(should be a series of servers, like DNS servers), which can provide the query service to every caller; local location server, which is maintained by local proxy server. Before the callee moves to another place, he registers with his local proxy, if his new place is in the same area of a specific local location server, the proxy only updates the database in the local location server in its domain. Otherwise, if the new place is out of the range of the local location server, the proxy requests to update the database in global location server. So if the callee moves frequently in a small area(that's quite possible in reality), no need to update the global location server from time to time, that is the usage of local location server. 2. If a caller wants to make a call, its local proxy only needs to query the global location server, then it can get the latest location of the callee, no need to tranverse many proxies to locate the callee. So in the second example, the P2, P3,P4 may be location server, AAA server, or other server which can provide subscribed services. How do you think about this scheme? Thanks for all reply. Yu > ---------- > From: Neil Deason[SMTP:ndeason@ubiquity.net] > Sent: Thursday, May 25, 2000 4:11 PM > To: Ge Yu > Cc: 'sip@lists.bell-labs.com ' > Subject: Re: [SIP] RE: about proxy > > Ge Yu wrote: > > > hi, Jonathan, > > > > Thanks for your fast reply. > > > > Actually it can be shown as following: > > > > The SIP original operation: > > > > (1) (2) (3) (4) (5) > > (caller)UAC--->proxy1--->proxy2--->proxy3--->proxy4--->UAS(callee) > > > > Different proxy provides different service, the services are provided > > sequentialy, all the (1),(2),(3),(4),(5) are standard SIP INVITE > messages. > > > > And another scheme: > > proxy2 proxy3 proxy4 > > (2)\ (3)/ (4)/ > > (caller)UAC---->(local)proxy1---->UAS(callee) > > (1) (5) > > > > Now the services of proxy2, proxy3, proxy4 can be provided parallelly. > The > > (1),(5) > > are still standard SIP INVITE messages. But the (2),(3),(4) are > simplified > > requests which > > only include the service provided by individual proxy, so (2),(3),(4) > > messages are different > > and only part of original INVITE. Proxy1 sends out 3 requests > > simultaneously, after it gets > > the 3 reponses from 3 proxies, it rewrite the original INVITE and sends > it > > to UAS. > > In the first example the service being performed by the SIP proxies is > trying to > locate the callee, by routing the INVITE on to the next appropriate hop. > > What are the services of P2, P3, P4 in your second example? > > Whatever they are I think describing nodes 2,3,4 as SIP Proxy Servers is > leading to confusion. However, if they are SIP nodes offering services, > that > fall within the solution space of SIP, it might be possible to add a new > SIP > request method to do what you are describing. > > hth, > 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 Thu May 25 06:44:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03054 for ; Thu, 25 May 2000 06:44:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB6254439D; Thu, 25 May 2000 06:35:42 -0400 (EDT) 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 4489044381 for ; Thu, 25 May 2000 06:35:40 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 25 06:43:33 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2C0E244344; Thu, 25 May 2000 06:30:24 -0400 (EDT) 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 8BB3A44341 for ; Thu, 25 May 2000 06:30:23 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 11:30:22 +0100 Message-ID: <57D6C2C01BD9D111A0BE0000C061C3F4023CAE8D@uk0006exch003u.uk.lucent.com> From: "Holland, Peter Michael (Peter)" To: sip@lists.bell-labs.com, "'Schroeder, Tim'" Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP Date: Thu, 25 May 2000 11:30:21 +0100 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Tim, > I agree that the information of type 1 is not relevant. I'm just a little > uncomfortable having the gateway on the BICC-to-SIP side edit out part of > the BICC message to keep the SIP network happy. It may edit out part of > the > BICC message for its own reasons (hiding the details of the source > network?) > but it shouldn't have to do so just because the SIP network can't > encapsulate BICC, but only straight ISUP. > > I don't know of any reason why it *couldn't* edit it out, it just seems > easier to pass along the whole BICC message transparently. The > destination > BICC network can choose to use the parts it thinks are useful, and to > ignore > the parts it thinks aren't. > The normal BICC processing at the receiving side of the BICC-to-SIP gateway will process and remove the type 1 information, because it is inherently link-by-link according to the BICC procedures. > In the ISUP case, we send the ISUP message transparently, without editing > out the parts known (or suspected) to be useless in the destination > network. > I like that model, and it seems easy enough to follow for BICC as well. > And > even if BICC looks a lot like ISUP, and after the useless information has > been removed may look exactly like ISUP, it still seems cleaner to > transmit > the BICC as encapsulated BICC, and label it as such with > "application/bicc" > or some such, rather than calling it ISUP. > I do not disagree with this in principle, but I do see a problem with how to indicate this with the Content-Type as currently in draft-ietf-sip-isup-mime-01. Considering that: 1. a SIP-to-ISUP gateway ought to be able to handle a mime'd message that originated from a previous BICC call segment, without being upgraded to understand a new "BICC" Content-Type. (so it should be "application/ISUP") 2. there will be regional and national variants of BICC, just as there are of ISUP. (so the version, and base parameters are still needed as defined.) The only reason I can see why a SIP-to-BICC gateway would be interested that a previous leg was BICC is if there is some Type 2 information included. It can easily detect that by looking in the message, so maybe this is a sufficient way of detecting this case. If this is not considered sufficient then an additional parameter should be added to the Content-Type - "BICC=y/n" > > The concern expressed refers to "converting to the ISUP format". I'm > not > sure > > what the concern really is, considering that the BICC message format is > the same > > as the ISUP message format, from the message type octet onwards. > > Annex E of the Q.1901 document is all about BICC-to-ISUP interworking. > The > differences don't seem substantial, but ... > The differences are not substantial. > If the BICC information is stripped of its BICC-ness and encapsulated as > ISUP, will the destination end even be able to tell that it used to be > BICC? > Could that ever be useful? > > Tim Schroeder > tschroeder@tri.sbc.com > SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 > > > Pete Holland Lucent Technologies, Malmesbury, UK email: pmholland@lucent.com phone: +44 1666 832423 fax: +44 1666 824515 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 25 06:59:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03257 for ; Thu, 25 May 2000 06:59:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 97EB844381; Thu, 25 May 2000 06:51:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 537A144366 for ; Thu, 25 May 2000 06:51:15 -0400 (EDT) Date: Thu, 25 May 2000 13:01:37 +0200 (CEST) From: Lars Berggren To: Alberto Conte Cc: IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description In-Reply-To: <392CF5FC.E49FAF7F@ms.alcatel.fr> Message-ID: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Thu, 25 May 2000, Alberto Conte wrote: > All, > > I would like to allow a user to send an INVITE message carrying an incomplete session > description specifying the list of media types to be used in the session without > indicating the RTP ports and addresses for receiving them. > If your intention is to only send streams, not to receive them, you can list them as sendonly (a=sendonly). See section B.2 in rfc2543 and rfc2327. /Lars > That should be useful in case of third-party control, or gateway between two > signalling protocols. > > I thought to something like this: > > v=0 > o=Alberto 2890844730 2890844730 IN IP4 100.101.102.103 > s=Hello! > t=0 0 > m=audio 0 RTP/AVP 3 > a=rtpmap:3 GSM/8000 > m=video 0 RTP/AVP 32 > a=rtpmap:32 MPV/90000 > > i.e. putting the port number to zero. > > Is it possible? Can be detailed in the next RFC? > > Thanks in advance fo the help, > Alberto > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 25 08:02:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05302 for ; Thu, 25 May 2000 08:02:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7499344366; Thu, 25 May 2000 07:54:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id 66D6C44336 for ; Thu, 25 May 2000 07:54:19 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id MAA00018; Thu, 25 May 2000 12:53:19 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA10789; Thu, 25 May 2000 14:02:25 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id OAA12702; Thu, 25 May 2000 14:02:24 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.33]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id OAA15764; Thu, 25 May 2000 14:02:21 +0200 (MET DST) Message-ID: <392D1650.C066559C@ms.alcatel.fr> Date: Thu, 25 May 2000 14:02:24 +0200 From: Alberto Conte Reply-To: Alberto.Conte@ms.alcatel.fr Organization: Alcatel - Corporate Research Center X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: it,en,fr MIME-Version: 1.0 To: Neil Deason Cc: IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: <75C79E507864D3118AFC00805FEAB7D85B272B@ripexch001.mcit.com> <392CF5FC.E49FAF7F@ms.alcatel.fr> <392CFCB8.3B21640@ubiquity.net> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Neil Deason a écrit : > > Alberto Conte wrote: > > > All, > > > > I would like to allow a user to send an INVITE message carrying an incomplete session > > description specifying the list of media types to be used in the session without > > indicating the RTP ports and addresses for receiving them. > > > > That should be useful in case of third-party control, or gateway between two > > signalling protocols. > > > > I thought to something like this: > > > > v=0 > > o=Alberto 2890844730 2890844730 IN IP4 100.101.102.103 > > s=Hello! > > t=0 0 > > m=audio 0 RTP/AVP 3 > > a=rtpmap:3 GSM/8000 > > m=video 0 RTP/AVP 32 > > a=rtpmap:32 MPV/90000 > > > > i.e. putting the port number to zero. > > > > Is it possible? Can be detailed in the next RFC? > > It already is used to infer a very different meaning from a callee to a caller. Look at > Appendix B - Usage of SDP ... > > "If the callee wants neither to send nor receive a stream offered by the caller, the > callee sets the port number of that stream to zero in its media stream." > > Cheers, > Neil. Thank you Neil for your answer. I know the content of Appendix B and I agree with you. However, as you say, the "port=0" meaning has been fixed only in the case of calle -> caller response or in a caller -> callee ACK, NOT in the caller -> callee INVITE message. I still think that is acceptable to state that the port=0 in an INVITE message means: "I invite you for a session according with these medias, but at the moment I don't have the RTP port and address". RTP port and address will be sent in the ACK! Note that in my case the caller is not asking for a send-only session, but only delaying the port and address information. Cheers, Alberto > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > 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 May 25 08:39:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00457 for ; Thu, 25 May 2000 08:39:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E882D44386; Thu, 25 May 2000 08:24:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id F096344336 for ; Thu, 25 May 2000 08:24:07 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id NAA18214; Thu, 25 May 2000 13:23:07 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA25425; Thu, 25 May 2000 14:32:16 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id OAA14626; Thu, 25 May 2000 14:32:03 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.33]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id OAA01985; Thu, 25 May 2000 14:32:01 +0200 (MET DST) Message-ID: <392D1D45.5259F3DF@ms.alcatel.fr> Date: Thu, 25 May 2000 14:32:05 +0200 From: Alberto Conte Reply-To: Alberto.Conte@ms.alcatel.fr Organization: Alcatel - Corporate Research Center X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: it,en,fr MIME-Version: 1.0 To: Lars Berggren Cc: Neil Deason , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Lars Berggren a écrit : > > On Thu, 25 May 2000, Alberto Conte wrote: > > > Neil Deason a écrit : > > > > > > Alberto Conte wrote: > > > > > > > All, > > > > > > > > I would like to allow a user to send an INVITE message carrying an incomplete session > > > > description specifying the list of media types to be used in the session without > > > > indicating the RTP ports and addresses for receiving them. > > > > > > > > That should be useful in case of third-party control, or gateway between two > > > > signalling protocols. > > > > > > > > I thought to something like this: > > > > > > > > v=0 > > > > o=Alberto 2890844730 2890844730 IN IP4 100.101.102.103 > > > > s=Hello! > > > > t=0 0 > > > > m=audio 0 RTP/AVP 3 > > > > a=rtpmap:3 GSM/8000 > > > > m=video 0 RTP/AVP 32 > > > > a=rtpmap:32 MPV/90000 > > > > > > > > i.e. putting the port number to zero. > > > > > > > > Is it possible? Can be detailed in the next RFC? > > > > > > It already is used to infer a very different meaning from a callee to a caller. Look at > > > Appendix B - Usage of SDP ... > > > > > > "If the callee wants neither to send nor receive a stream offered by the caller, the > > > callee sets the port number of that stream to zero in its media stream." > > > > > > Cheers, > > > Neil. > > > > Thank you Neil for your answer. > > > > I know the content of Appendix B and I agree with you. However, as you say, the > > "port=0" meaning has been fixed only in the case of calle -> caller response or in a > > caller -> callee ACK, NOT in the caller -> callee INVITE message. > > > > I still think that is acceptable to state that the port=0 in an INVITE message means: > > "I invite you for a session according with these medias, but at the moment I don't > > have the RTP port and address". > > > > RTP port and address will be sent in the ACK! > > > > Note that in my case the caller is not asking for a send-only session, but only > > delaying the port and address information. > > In this case you can send an INVITE without SDP, the callee lists streams > in the 200, and the ACK can contain the final SDP. This behaviour is > referenced in the spec. /Lars > Sorry Lars, I don't agree with you. Sending an INVITE without SDP means that the caller will be forced to choose the medias exchanged in the session on the base of the ones proposed by the callee! This is not exactly what I want. I would like the caller able to force the callee to accept its choice (or a part) of the medias, delaying only the RTP port and address information. > > > > Cheers, > > Alberto > > > > > -- > > > Ubiquity Software Corporation, UK http://www.ubiquity.net > > > > > > _______________________________________________ > > > 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 > > > > Lars Berggren > Intertex Data AB tel: +46-8-6282828 > Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 25 09:01:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04048 for ; Thu, 25 May 2000 09:01:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C99E0443B8; Thu, 25 May 2000 08:52:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 99F5744336 for ; Thu, 25 May 2000 08:52:37 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA28947; Thu, 25 May 2000 13:59:03 +0100 (BST) Message-ID: <392D2397.EA6AFAC8@ubiquity.net> Date: Thu, 25 May 2000 13:59:03 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alberto.Conte@ms.alcatel.fr Cc: Lars Berggren , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: <392D1D45.5259F3DF@ms.alcatel.fr> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Alberto Conte wrote: > Lars Berggren a écrit : > > > > In this case you can send an INVITE without SDP, the callee lists streams > > in the 200, and the ACK can contain the final SDP. This behaviour is > > referenced in the spec. /Lars > > > > Sorry Lars, I don't agree with you. > > Sending an INVITE without SDP means that the caller will be forced to choose the > medias exchanged in the session on the base of the ones proposed by the callee! > > This is not exactly what I want. I would like the caller able to force the callee to > accept its choice (or a part) of the medias, delaying only the RTP port and address > information. But by specifying the medias in an INVITE you don't 'force' the callee to accept the caller's choice. It is the opening offer in the two parties agreeing on media types. If you do not include the session description in the INVITE, the other party should offer it's supported media streams and codecs in its 1xx or 2xx response. Your UA then sends a completed session description in the ACK. 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 Thu May 25 09:58:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08497 for ; Thu, 25 May 2000 09:58:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA45144357; Thu, 25 May 2000 09:50:00 -0400 (EDT) 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 757BB44336 for ; Thu, 25 May 2000 09:49:58 -0400 (EDT) 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 JAA13511 for ; Thu, 25 May 2000 09:58:17 -0400 (EDT) Message-ID: <392D3179.9D014BDC@cs.columbia.edu> Date: Thu, 25 May 2000 09:58:17 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [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] Content-Function vs. Content-Disposition Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Based on earlier separate threads, we currently have both Content-Function and Content-Disposition in the 2543bis draft. They seem to overlap to some large extent, so a decision needs to be reached as to whether they are truly different things or just one and, if one, which of the two to pick. Content-Disposition is an existing concept (RFC 2183), while Content-Function is not used outside of SIP. My preference would be to stick with Content-Disposition. -- 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 May 25 10:35:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09705 for ; Thu, 25 May 2000 10:35:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C3CC443A3; Thu, 25 May 2000 08:00:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id F178B44386 for ; Thu, 25 May 2000 08:00:07 -0400 (EDT) Date: Thu, 25 May 2000 14:10:04 +0200 (CEST) From: Lars Berggren To: Alberto Conte Cc: Neil Deason , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description In-Reply-To: <392D1650.C066559C@ms.alcatel.fr> Message-ID: MIME-Version: 1.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA09705 On Thu, 25 May 2000, Alberto Conte wrote: > Neil Deason a écrit : > > > > Alberto Conte wrote: > > > > > All, > > > > > > I would like to allow a user to send an INVITE message carrying an incomplete session > > > description specifying the list of media types to be used in the session without > > > indicating the RTP ports and addresses for receiving them. > > > > > > That should be useful in case of third-party control, or gateway between two > > > signalling protocols. > > > > > > I thought to something like this: > > > > > > v=0 > > > o=Alberto 2890844730 2890844730 IN IP4 100.101.102.103 > > > s=Hello! > > > t=0 0 > > > m=audio 0 RTP/AVP 3 > > > a=rtpmap:3 GSM/8000 > > > m=video 0 RTP/AVP 32 > > > a=rtpmap:32 MPV/90000 > > > > > > i.e. putting the port number to zero. > > > > > > Is it possible? Can be detailed in the next RFC? > > > > It already is used to infer a very different meaning from a callee to a caller. Look at > > Appendix B - Usage of SDP ... > > > > "If the callee wants neither to send nor receive a stream offered by the caller, the > > callee sets the port number of that stream to zero in its media stream." > > > > Cheers, > > Neil. > > Thank you Neil for your answer. > > I know the content of Appendix B and I agree with you. However, as you say, the > "port=0" meaning has been fixed only in the case of calle -> caller response or in a > caller -> callee ACK, NOT in the caller -> callee INVITE message. > > I still think that is acceptable to state that the port=0 in an INVITE message means: > "I invite you for a session according with these medias, but at the moment I don't > have the RTP port and address". > > RTP port and address will be sent in the ACK! > > Note that in my case the caller is not asking for a send-only session, but only > delaying the port and address information. In this case you can send an INVITE without SDP, the callee lists streams in the 200, and the ACK can contain the final SDP. This behaviour is referenced in the spec. /Lars > > Cheers, > Alberto > > > -- > > Ubiquity Software Corporation, UK http://www.ubiquity.net > > > > _______________________________________________ > > 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 > Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 25 10:39:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10069 for ; Thu, 25 May 2000 10:39:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 792CE443BA; Thu, 25 May 2000 10:30:53 -0400 (EDT) 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 EB6B644336 for ; Thu, 25 May 2000 10:30:46 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FV400I01E0YO6@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 25 May 2000 14:38:58 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FV400EHLE0XMV@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 25 May 2000 14:38:58 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FV400L01DTXT0@pmismtp04.wcomnet.com> for sip@lists.bell-labs.com; Thu, 25 May 2000 14:34:45 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FV400L01DTVST@pmismtp04.wcomnet.com> for sip@lists.bell-labs.com; Thu, 25 May 2000 14:34:45 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FV400GLWDTI9I@pmismtp04.wcomnet.com> for sip@lists.bell-labs.com; Thu, 25 May 2000 14:34:30 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Thu, 25 May 2000 14:38:38 +0000 Content-return: allowed Date: Thu, 25 May 2000 14:38:36 +0000 From: "Sinnreich, Henry" To: "'sip@lists.bell-labs.com '" Message-id: <75C79E507864D3118AFC00805FEAB7D85B2736@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=iso-8859-1 Subject: [SIP] SIP Rules! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com You may have seen it, but here is the URL: http://commweb.com/features/comptel/2k0522.sip.html Henry >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 May 25 10:52:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10353 for ; Thu, 25 May 2000 10:52:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88891443AF; Thu, 25 May 2000 08:14:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 8D250443AE for ; Thu, 25 May 2000 08:14:12 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Thu, 25 May 2000 13:20:04 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 13:20:02 +0100 Message-ID: <61ABD11436FED21192440000F81F3E36045DCFA8@nwcwi1a.europe.nortel.com> From: "Mark Watson" To: "'Schroeder, Tim'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP Date: Thu, 25 May 2000 13:19:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC643.8BE437E2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFC643.8BE437E2 Content-Type: text/plain; charset="iso-8859-1" Tim, If we followed your proposal, then there would be no way for CS(C) to distibguish between case (i) and case (ii). In both cases, CS(C) would receive a SIP INVITE message containing a BICC IAM (itself containing Bearer Control information) and also Bearer COntrol information within the SDP. In case (i), the BICC APM information will relate to the MG controlled by CS(A) (MG(A)), as will the SDP. In case (ii), the BICC APM information will related to MG(A) and the SDP will relate to MG(B). The only sensible behaviour for CS(C) is to use the SDP in both cases, so the BICC information will never be used, even in the BICC -- SIP -- BICC case. The BICC APM is essentially 'link by link' between Call Servers. It is required that CS(B) can interpret this information and so implicitly it has the capability to remove it, turning the BICC message back into an ISUP one. It will be easier to come to a clear conclusion on this one when we have a better idea of how BICC will support IP. One option being discussed is that BICC will support carriage of SDP information, which will be 'tunnelled' transparently from one MG, via the Call Servers, to the next MG. This information would be rather easy to interwork to SIP. Regards, Mark Watson Nortel Networks -----Original Message----- From: Schroeder, Tim [mailto:schroeder@tri.sbc.com] Sent: 23 May 2000 22:25 To: sip@lists.bell-labs.com Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP Mark Watson [mailto:mwatson@nortelnetworks.com] writes: If we have CS(A) --bicc ---CS(B)---sip --- CS(C)---bicc---CS(D) where 'CS' is 'Call Server', for want of a better term, then there are two cases: (i) with the bearer path routed directly between Gateways controlled by CS(A) and CS(D), and (ii) with further 'packet-to-packet' gateways contolled by CS(B) and CS(C) i.e. there are three 'domains' which are physically interworked at both the call and bearer layer. There is some doubt as to whether (i) will be possible at all - this depends on how the support of IP in BICC is defined over the next few months. If it is possible, I think that it should involve maping the bearer control mechanism in BICC to the equivalent in SIP (SDP) so that the call can still work if it terminates on a pure SIP agent. Agreed. If you do this mapping, then you've removed from the BICC information everything which makes it BICC and not ISUP, so you're not carrying BICC inside SIP at all. But just because you map the information from BICC into SIP, doesn't mean it's removed from the BICC message, does it? In the ISUP--SIP--ISUP case, the ISUP information that makes sense to map to SIP (to provide the desired level of interworking) is mapped, but the ISUP message is still passed along in the body to allow for ISUP transparency, in case the call ends up back on an ISUP-signaled network. I'd think the same mechanism would apply to the BICC--SIP--BICC case: map the BICC information that makes sense to SIP (and the bearer stuff to SDP), but pass along the original BICC message in the body. Then if the call terminates in the SIP-signaled network, you've got your interworking (to the level that you coherently mapped the BICC information to SIP/SDP), and if the call is routed through a gateway back to a BICC-signaled network you can still have "BICC transparency". In case (ii), the three domains are completely independent from each other when it comes to setup of the bearer connection. Again, the only information from BICC left to carry over the SIP domain is the ISUP part. I think I'd still want to send the whole BICC message, even if the non-ISUP part will never be used. The gateways provide the interworking functionality between BICC and SIP; there's no need to have them also interwork between BICC and ISUP (even if that's relatively easy) just so I can avoid an application/BICC or application/Q.1901 MIME type. If we were to carry the BICC APM parameter, which contains the Bearer related information, over SIP, we would be inventing a new way of carrying out bearer setup on a SIP call - an alternative to SDP. I do not think we should do this as it would be non-backwards-compatible. In your case (i), interwork the bearer related information to SDP (which will get used if the call terminates in the SIP-signaled network, ignoring the BICC-embedded APM parameter) and leave it in the BICC message as well, passing the whole BICC message along in the body (which will get used if the call is routed back to the BICC-signaled network). In your case (ii), the gateways are going to have to piece together the three media streams end-to-end, a first BICC APM parameter will describe the CS(A)--CS(B) segment, SDP will describe the CS(B)--CS(C) segment, and a second BICC APM parameter will describe the CS(C)--CS(D) segment. I don't think there's much BICC/APM-to-SDP interworking that can be done there, but the BICC message may as well be passed along, rather than first converting it to the ISUP format. Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01BFC643.8BE437E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Carrying Q.BICC as an Mime-type in SIP

Tim,

If we followed your proposal, then there would be no = way for CS(C) to distibguish between case (i) and case (ii). In both = cases, CS(C) would receive a SIP INVITE message containing a BICC IAM = (itself containing Bearer Control information) and also Bearer COntrol = information within the SDP.

In case (i), the BICC APM information will relate to = the MG controlled by CS(A) (MG(A)), as will the SDP.

In case (ii), the BICC APM information will related = to MG(A) and the SDP will relate to MG(B).

The only sensible behaviour for CS(C) is to use the = SDP in both cases, so the BICC information will never be used, even in = the BICC -- SIP -- BICC case.

The BICC APM is essentially 'link by link' between = Call Servers. It is required that CS(B) can interpret this information = and so implicitly it has the capability to remove it, turning the BICC = message back into an ISUP one.

It will be easier to come to a clear conclusion on = this one when we have a better idea of how BICC will support IP. One = option being discussed is that BICC will support carriage of SDP = information, which will be 'tunnelled' transparently from one MG, via = the Call Servers, to the next MG. This information would be rather easy = to interwork to SIP.

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: Schroeder, Tim [mailto:schroeder@tri.sbc.com]<= /FONT>
Sent: 23 May 2000 22:25
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Carrying Q.BICC as an Mime-type = in SIP


Mark Watson [mailto:mwatson@nortelnetworks= .com] writes:

 If we have CS(A) --bicc ---CS(B)---sip --- = CS(C)---bicc---CS(D)

where 'CS' is 'Call Server', for want of a better = term, then there are two
cases:

(i) with the bearer path routed directly between = Gateways controlled by
CS(A) and CS(D), and

(ii) with further 'packet-to-packet' gateways = contolled by CS(B) and CS(C)
i.e. there are three 'domains' which are physically = interworked at both the
call and bearer layer.

There is some doubt as to whether (i) will be = possible at all - this depends
on how the support of IP in BICC is defined over the = next few months. If it
is possible, I think that it should involve maping = the bearer control
mechanism in BICC to the equivalent in SIP (SDP) so = that the call can still
work if it terminates on a pure SIP agent.

Agreed.

If you do this mapping, then you've removed from the = BICC information
everything which makes it BICC and not ISUP, so = you're not carrying BICC
inside SIP at all.

But just because you map the information from BICC = into SIP, doesn't mean
it's removed from the BICC message, does it?  = In the ISUP--SIP--ISUP case,
the ISUP information that makes sense to map to SIP = (to provide the desired
level of interworking) is mapped, but the ISUP = message is still passed along
in the body to allow for ISUP transparency, in case = the call ends up back on
an ISUP-signaled network.  I'd think the same = mechanism would apply to the
BICC--SIP--BICC case: map the BICC information that = makes sense to SIP (and
the bearer stuff to SDP), but pass along the = original BICC message in the
body.  Then if the call terminates in the = SIP-signaled network, you've got
your interworking (to the level that you coherently = mapped the BICC
information to SIP/SDP), and if the call is routed = through a gateway back to
a BICC-signaled network you can still have = "BICC transparency".

In case (ii), the three domains are completely = independent from each other
when it comes to setup of the bearer connection. = Again, the only information
from BICC left to carry over the SIP domain is the = ISUP part.

I think I'd still want to send the whole BICC = message, even if the non-ISUP
part will never be used.  The gateways provide = the interworking
functionality between BICC and SIP; there's no need = to have them also
interwork between BICC and ISUP (even if that's = relatively easy) just so I
can avoid an application/BICC or application/Q.1901 = MIME type.

If we were to carry the BICC APM parameter, which = contains the Bearer
related information, over SIP, we would be inventing = a new way of carrying
out bearer setup on a SIP call - an alternative to = SDP. I do not think we
should do this as it would be = non-backwards-compatible.

In your case (i), interwork the bearer related = information to SDP (which
will get used if the call terminates in the = SIP-signaled network, ignoring
the BICC-embedded APM parameter) and leave it in the = BICC message as well,
passing the whole BICC message along in the body = (which will get used if the
call is routed back to the BICC-signaled = network). 

In your case (ii), the gateways are going to have to = piece together the
three media streams end-to-end, a first BICC APM = parameter will describe the
CS(A)--CS(B) segment, SDP will describe the = CS(B)--CS(C) segment, and a
second BICC APM parameter will describe the = CS(C)--CS(D) segment.  I don't
think there's much BICC/APM-to-SDP interworking that = can be done there, but
the BICC message may as well be passed along, rather = than first converting
it to the ISUP format.

Tim Schroeder
tschroeder@tri.sbc.com
SBC Technology Resources, 9505 Arboretum Blvd., = Austin, TX  78759

 


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

------_=_NextPart_001_01BFC643.8BE437E2-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 25 11:00:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10518 for ; Thu, 25 May 2000 11:00:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 66C9A443BE; Thu, 25 May 2000 10:52:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9EBDE443BD for ; Thu, 25 May 2000 10:52:26 -0400 (EDT) Received: from dynamicsoft.com ([63.89.18.23]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA12929; Thu, 25 May 2000 11:02:09 -0400 (EDT) Message-ID: <392D4311.FDF27E1C@dynamicsoft.com> Date: Thu, 25 May 2000 11:13:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sinnreich, Henry" Cc: "'sip@lists.bell-labs.com '" Subject: Re: [SIP] SIP Rules! References: <75C79E507864D3118AFC00805FEAB7D85B2736@ripexch001.mcit.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Let me add that that story was the cover article of the May Computer Telephony Magazine. The cover itself is very amusing.... I encourage people to pick up a copy. -Jonathan R. "Sinnreich, Henry" wrote: > > You may have seen it, but here is the URL: > http://commweb.com/features/comptel/2k0522.sip.html > > Henry > > >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 -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 25 11:02:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10680 for ; Thu, 25 May 2000 11:02:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A4349443C5; Thu, 25 May 2000 10:53:34 -0400 (EDT) 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 8556C443C4 for ; Thu, 25 May 2000 10:53:31 -0400 (EDT) Received: from dynamicsoft.com ([63.89.18.34]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id KAA24115; Thu, 25 May 2000 10:02:51 -0500 Message-ID: <392D4028.91094F47@dynamicsoft.com> Date: Thu, 25 May 2000 11:00:56 -0400 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Oran Cc: "Roy, Radhika R, ALARC" , Michael Thomas , IETF SIP Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ping doesn't really tell me much about load distribution between traffic priorities, nor about timing variations. Maybe a priority PING . . . -- Dean Dave Oran wrote: > > > Or maybe we need a general "Hey, how's the net doing?" protocol . . . > > > Ping? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu May 25 11:04:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10714 for ; Thu, 25 May 2000 11:04:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 963BC443CB; Thu, 25 May 2000 10:56:19 -0400 (EDT) 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 33160443C4 for ; Thu, 25 May 2000 10:56:17 -0400 (EDT) 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 LAA20404 for ; Thu, 25 May 2000 11:04:40 -0400 (EDT) Message-ID: <392D4107.B2543E8A@cs.columbia.edu> Date: Thu, 25 May 2000 11:04:39 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [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] Contact in OPTIONS Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Currently, Contact is optional for OPTIONS. While this is harmless, it is not quite clear what this Contact would mean in this context. It could mean "send future requests here", if used within an existing call. Any preferences? -- 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 May 25 11:06:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10768 for ; Thu, 25 May 2000 11:06:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B009E443D1; Thu, 25 May 2000 10:56:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A9021443CC for ; Thu, 25 May 2000 10:56:19 -0400 (EDT) Received: from dynamicsoft.com ([63.89.18.23]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA12962; Thu, 25 May 2000 11:05:43 -0400 (EDT) Message-ID: <392D43E7.CC2F69C2@dynamicsoft.com> Date: Thu, 25 May 2000 11:16:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Alberto.Conte@ms.alcatel.fr, Lars Berggren , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: <392D1D45.5259F3DF@ms.alcatel.fr> <392D2397.EA6AFAC8@ubiquity.net> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Another way to do it is to send the initial INVITE with the desired media streams on hold (IP address set to 0.0.0.0). When you have specific IP address and port information, you can do a re-INVITE, and take the user off hold by passing an updated IP address and port in each m line. Note that the update would not occur in an ACK, but rather in a re-INVITE. -Jonathan R. Neil Deason wrote: > > Alberto Conte wrote: > > > Lars Berggren a écrit : > > > > > > > > > In this case you can send an INVITE without SDP, the callee lists streams > > > in the 200, and the ACK can contain the final SDP. This behaviour is > > > referenced in the spec. /Lars > > > > > > > Sorry Lars, I don't agree with you. > > > > Sending an INVITE without SDP means that the caller will be forced to choose the > > medias exchanged in the session on the base of the ones proposed by the callee! > > > > This is not exactly what I want. I would like the caller able to force the callee to > > accept its choice (or a part) of the medias, delaying only the RTP port and address > > information. > > But by specifying the medias in an INVITE you don't 'force' the callee to accept the caller's > choice. It is the opening offer in the two parties agreeing on media types. If you do not include > the session description in the INVITE, the other party should offer it's supported media streams > and codecs in its 1xx or 2xx response. Your UA then sends a completed session description in the > ACK. > > 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 -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 25 11:23:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11192 for ; Thu, 25 May 2000 11:23:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A106443BC; Thu, 25 May 2000 11:14:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3AAE844336 for ; Thu, 25 May 2000 11:14:43 -0400 (EDT) Received: from dynamicsoft.com ([63.89.18.23]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA13106; Thu, 25 May 2000 11:24:20 -0400 (EDT) Message-ID: <392D4842.525E30AF@dynamicsoft.com> Date: Thu, 25 May 2000 11:35:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <392D4107.B2543E8A@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit To date, OPTIONS has been one of those "outside of the call" methods which has no impact on call state. Changing the address for routing subsequent requests was something I thought was handled through re-INVITE; having this also happen through OPTIONS seems to add another thing to check for, and also means that OPTIONS now has an effect on calls, when it didn't before. A reasonable use for Contact in OPTIONS (and its response) is to list the communications means available for establishing new sessions or other things. For example: OPTIONS sip:hgs@cs.columbia.edu SIP/2.0 From: sip:jdrosen@dynamicsoft.com Contact: sip:jdrosen@dynamicsoft.com, http://www.cs.columbia.edu ,mailto:jdrosen@dynamicsoft.com and the reply contains Contact headers with the same thing. -Jonathan . Henning Schulzrinne wrote: > > Currently, Contact is optional for OPTIONS. While this is harmless, it > is not quite clear what this Contact would mean in this context. It > could mean "send future requests here", if used within an existing call. > Any preferences? > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 25 12:06:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12301 for ; Thu, 25 May 2000 12:05:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA1AA44375; Thu, 25 May 2000 11:57:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id E565444370 for ; Thu, 25 May 2000 11:57:15 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id QAA14935; Thu, 25 May 2000 16:56:15 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA11947; Thu, 25 May 2000 18:05:17 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id SAA27786; Thu, 25 May 2000 18:05:06 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.33]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id SAA24140; Thu, 25 May 2000 18:05:02 +0200 (MET DST) Message-ID: <392D4F2A.9571F52F@ms.alcatel.fr> Date: Thu, 25 May 2000 18:04:58 +0200 From: Alberto Conte Reply-To: Alberto.Conte@ms.alcatel.fr Organization: Alcatel - Corporate Research Center X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: it,en,fr MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Neil Deason , Lars Berggren , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: <392D1D45.5259F3DF@ms.alcatel.fr> <392D2397.EA6AFAC8@ubiquity.net> <392D43E7.CC2F69C2@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Putting in hold the calle is a solution, but that increases the number of messages to be exchanged, requiring a re-INVITE transaction! The power of SIP is to reduce the message exchanged in case of no error. And this is actually a case of no-error. It should be better allowing the caller to propose its media request delaying only the RTP port information in the ACK. Alberto Jonathan Rosenberg wrote : > > Another way to do it is to send the initial INVITE with the desired > media streams on hold (IP address set to 0.0.0.0). When you have > specific IP address and port information, you can do a re-INVITE, and > take the user off hold by passing an updated IP address and port in each > m line. Note that the update would not occur in an ACK, but rather in a > re-INVITE. > > -Jonathan R. > > Neil Deason wrote: > > > > Alberto Conte wrote: > > > > > Lars Berggren a écrit : > > > > > > > > > > > > > > In this case you can send an INVITE without SDP, the callee lists streams > > > > in the 200, and the ACK can contain the final SDP. This behaviour is > > > > referenced in the spec. /Lars > > > > > > > > > > Sorry Lars, I don't agree with you. > > > > > > Sending an INVITE without SDP means that the caller will be forced to choose the > > > medias exchanged in the session on the base of the ones proposed by the callee! > > > > > > This is not exactly what I want. I would like the caller able to force the callee to > > > accept its choice (or a part) of the medias, delaying only the RTP port and address > > > information. > > > > But by specifying the medias in an INVITE you don't 'force' the callee to accept the caller's > > choice. It is the opening offer in the two parties agreeing on media types. If you do not include > > the session description in the INVITE, the other party should offer it's supported media streams > > and codecs in its 1xx or 2xx response. Your UA then sends a completed session description in the > > ACK. > > > > 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 > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 May 25 12:33:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13219 for ; Thu, 25 May 2000 12:33:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA10444377; Thu, 25 May 2000 12:25:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id 0EB1B44370 for ; Thu, 25 May 2000 12:25:12 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA7389; Thu, 25 May 2000 12:33:39 -0400 From: "Dave Oran" To: "Jiri Kuthan" Cc: "Dean Willis" , "Michael Thomas" , "IETF SIP" Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task force in Adelaide) Date: Thu, 25 May 2000 12:33:32 -0400 Message-ID: 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) In-Reply-To: <392C5408.42CD09E5@fokus.gmd.de> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jiri Kuthan > Sent: Wednesday, May 24, 2000 6:13 PM > To: Dave Oran > Cc: Dean Willis; Michael Thomas; IETF SIP > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task > force in Adelaide) > > > Dave, > > In the DiffServ case, I see these policies to control the edge: > > 0) no control; the edge trusts end-devices absolutely; end-devices > will get what they want > -> not very secure It also provides no traffic isloation, so one badly behaving host can degrade or deny service for a whole class. Call this a security problem if you want, but I don't. Diffserv by itself doesn't do "admission control", only aggregate policing. > 1) self-control; the edge manages itself; it uses some heuristics to say > which packet deserves which class > -> heuristics may fail If you believe Diffserv BY ITSELF is adequate, then by definition the heuristics don't fail. They only determine who wins and loses when the policing starts remarking or tossing packets. > 2) the edge is polled/controlled explicitly by > a) end-devices > ->they have some built-in control support, e.g. RSVP mapped to > DiffServe at the edge Yes. > b) proxies on behalf of the end-devices > ->works w/o changes to end-devices Define "works". I'm skeptical. This requires that the proxy knows enough about the topology to know where the end-device hits the edge, and knows enough about the current SLAs and policing parameters at that edge device to know if allowing the call will exceed the SLA and trigger aggregate policing. > ->application-awareness may be added on top of the > admission control, e.g. a SIP/RTSP/quake proxy will be > able to decide that all video streams from > head of department will be assigned high > priority > This is a completely independent issue. RSVP and COPS now have priority/preemption objects which allow admission control to take this kind of policy into account. > The question: Is 2b an invalid policy? I'm a registered skeptic. I don't think it has well defined properties such that you can explain either to a customer or an end user why the system behaves in a certain way. If you buy the notion that you don't need resource-availability-based admission control and traffic isolation to confine the effects of oversubscription, then I suppose 2b is workable. I wouldn't buy it. Someone else might. > Is it a > useful policy? And what is actually the difference in terms > of scalability between > i) end-devices trying to control/poll the edge [2a] > ii) farm of SIP proxies doing the same on behalf of them > (possibly using some kind of aggregation) [2b]? > The scalability bottleneck is the edge in both cases, Not really. The edge is in fact the only place where I think the scalability problem is tractable, because that's the point where the policing is done. > isn't it? > > Thanks, > > Jiri > > Dave Oran wrote: > > > > Ah. I understand. no RSVP == no explicit admission control. > > That's the bug. Hijacking SIP proxies to do the job of a bandwidth > > allocation and admission control signaling protocol is ugly at > best. You'd > > need one of these beasts for every application in the universe - rtsp, > > quake, you name it. > > > > If you build SIP proxies the way some people build web server > farms you'll > > have an entirely different scaling problem, which is 100's of > SIP proxies > > polling a poor overworked network managmeent system trying to figure out > > what it knows about the state of the core (or better stated, > what it knew > > about the core 5 minutes ago when it last gathered enough > measurements to > > make a guess). > > > > Register me as a skeptic. > > > > Dave. > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > > > Sent: Wednesday, May 24, 2000 3:53 PM > > > To: Dave Oran > > > Cc: Dean Willis; Michael Thomas; IETF SIP > > > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task > > > force in Adelaide) > > > > > > > > > > > > > > > Dave Oran wrote: > > > > > > > > If you're using Intserv at the edge the router at the edge of > > > the Diffserv > > > > cloud will likely know this and reject the reservation. No > need for the > > > > proxy to get involved. > > > > > > In general, I'm not. The WorldCom net, for example, is > TOS-priority from > > > end to end. > > > > > > > > > > > The car analogy is not a good one because in the case of > highways you're > > > > already stuck at the bottleneck when you find out you're > > > screwed, as opposed > > > > to RSVP when you are essentailly clearing all the dead wrecks > > > out of your > > > > way before driving up the highway, ala Mad Max. > > > > > > > > Positing that a SIP proxy has a better idea what the QoS > state of the > > > > Diffserv core is than the edge router at the edge of that > core is like > > > > saying the radio announcer knows more about the tornado > than the Twister > > > > crew chasing it. > > > > > > A SIP proxy is in a better position to have a persistent relationship > > > with a network management system which can feed it > information about the > > > state of the network than a dynamically romin SIP UA is. So, > even though > > > the announceer may not know as much about the tornado as the chaser > > > does, he is in a MUCH better position to share that > information with the > > > listening audience. > > > > > > > If there's a oracle which knows the state of the core it can > > > tell the edges > > > > as easily or MORE easily than it can tell an undefined sea of > > > application > > > > proxy boxes. > > > > > > Sure, the edges probably know truckloads of cool stuff. > > > > > > But I have no mechanism for the edges to relay this knowledge to the > > > UAs. > > > > > > -- > > > Dean > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Jiri Kuthan Phone: +49-30-3463 7271 > GMD FOKUS Fax : +49-30-3463 8271 > Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de > D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan > -- > Curious about Internet Telephony? > Check http://www.fokus.gmd.de/glone/projects/ipt today! > > > _______________________________________________ > 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 May 25 18:04:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21804 for ; Thu, 25 May 2000 18:04:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9BB4C44359; Thu, 25 May 2000 17:55:39 -0400 (EDT) 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 0F01944336 for ; Thu, 25 May 2000 17:55:37 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu May 25 18:02:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C18DC44344; Thu, 25 May 2000 17:49:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9232744341 for ; Thu, 25 May 2000 17:49:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2878852C4; Thu, 25 May 2000 17:49:33 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3990F52B6 for ; Thu, 25 May 2000 17:49:30 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu May 25 17:47:41 EDT 2000 Received: from thumper.research.telcordia.com ([128.96.41.1]) by dusty; Thu May 25 17:47:40 EDT 2000 Received: from research.telcordia.com (shim-pc [192.4.8.82]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e4PLlYg21166; Thu, 25 May 2000 17:47:34 -0400 (EDT) Message-ID: <392D9F75.278396A7@research.telcordia.com> Date: Thu, 25 May 2000 17:47:33 -0400 From: Hyong Sop Shim Organization: Telcordia Technologies X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com References: <410B13D70EB2D211827E00E0291E9FF7B2BCF4@ORT-MAIL> <39238277.963763CC@dynamicsoft.com> <39258FFF.6D51A10A@research.telcordia.com> <3925A7C3.D1422138@dynamicsoft.com> <39295F4F.4227A45@research.telcordia.com> <3929F71B.1C2D68EF@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Error in "SIP Call Control Services"? - was [SIP]Multimedia Conferencing using SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit In Figure 4 in 8.3 Add Party during Add Party, D, acting on the untriggered INVITE message from B, sends an INVITE message to A, "INV A Also:A, B." But, shouldn't this INVITE message from D be "INV A Also:B ReqBy:B" instead? --Hyong _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 00:35:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28320 for ; Fri, 26 May 2000 00:35:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A03044359; Fri, 26 May 2000 00:27:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AF1C544357 for ; Fri, 26 May 2000 00:27:05 -0400 (EDT) Received: from dynamicsoft.com (1Cust112.tnt2.freehold.nj.da.uu.net [63.17.114.112]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA15890; Fri, 26 May 2000 00:36:50 -0400 (EDT) Message-ID: <392E0204.F4C775EB@dynamicsoft.com> Date: Fri, 26 May 2000 00:48:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Content-Function vs. Content-Disposition References: <392D3179.9D014BDC@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit They definitely should be consolidated. Since inline, at least, does make sense for us, I would vote to use the HTTP version, Content-Disposition. We definitely need to also have the optional/required bit, which is critical for correct multipart usage. -Jonathan R. Henning Schulzrinne wrote: > > Based on earlier separate threads, we currently have both > Content-Function and Content-Disposition in the 2543bis draft. They seem > to overlap to some large extent, so a decision needs to be reached as to > whether they are truly different things or just one and, if one, which > of the two to pick. Content-Disposition is an existing concept (RFC > 2183), while Content-Function is not used outside of SIP. My preference > would be to stick with Content-Disposition. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 26 00:51:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28387 for ; Fri, 26 May 2000 00:51:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BAD144370; Fri, 26 May 2000 00:43:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3D43344357 for ; Fri, 26 May 2000 00:43:07 -0400 (EDT) Received: from dynamicsoft.com (1Cust112.tnt2.freehold.nj.da.uu.net [63.17.114.112]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA15898; Fri, 26 May 2000 00:49:09 -0400 (EDT) Message-ID: <392E04E8.9EF7B31@dynamicsoft.com> Date: Fri, 26 May 2000 01:00:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] draft-rosenberg-sip-guidelines-00.txt References: <392BFE60.8BE09351@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > This draft states that a probing mechanism should be defined to aid > backwards compatibility when defining new methods. It describes the > mechanism to be used as the UAC adding some header to a standard SIP > request. The UAS places some information in the response if it > understands this header (and thus the extension-method). > > Couldn't the OPTIONS method be used to provide such a probing mechanism > within the standard SIP framework? The response to an OPTIONS request > should include an Allow header entity-field that lists the supported set > of headers, including any extension-methods. Well, Allow lists allowed methods, not new extensions. New extensions are listed in the Supported header. Since this draft was published, there was some consensus on the list that the response to INVITE should probably contain both Allow and Supported headers (and possibly even Accept). The particular application was TRANSFER; it would be nice to know once the call is set up whether the remote side can be transferred. This would allow you to "grey out" the transfer button on the UI, rather than having the user try and then fail. This would eliminate the need for the probing mechanism, and avoid the need for the explicit OPTIONS. Suggested wording: "A 200 OK response to the initial INVITE for a call SHOULD contain the Allow and Supported headers, and MAY contain the Accept header. These will enable the UAC to determine the features and extensions supported by the UAS for the duration of the call. Similarly, the initial INVITE from the UAC SHOULD contain the Allow and Supported headers, and MAY contain the Accept header." -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 26 04:30:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11319 for ; Fri, 26 May 2000 04:30:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D15CB44357; Fri, 26 May 2000 04:22:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 5C89B44342 for ; Fri, 26 May 2000 04:22:14 -0400 (EDT) Date: Fri, 26 May 2000 10:23:13 +0200 (CEST) From: Lars Berggren To: Alberto Conte Cc: Jonathan Rosenberg , Neil Deason , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description In-Reply-To: <392D4F2A.9571F52F@ms.alcatel.fr> Message-ID: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Thu, 25 May 2000, Alberto Conte wrote: > Putting in hold the calle is a solution, but that increases the number of messages to > be exchanged, requiring a re-INVITE transaction! > > The power of SIP is to reduce the message exchanged in case of no error. And this is > actually a case of no-error. It should be better allowing the caller to propose its > media request delaying only the RTP port information in the ACK. > > Alberto > I would rather think the power of SIP is its generality, flexibility and simplicity. A re-INVITE is a very general and powerful mechanism to accomplish many different tasks, including yours, so why not keep it that way instead of specifying special cases which tend to make the protocol more complex. /Lars Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 04:50:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11456 for ; Fri, 26 May 2000 04:50:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 74D7E44366; Fri, 26 May 2000 04:42:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 8391E44365 for ; Fri, 26 May 2000 04:41:41 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA03672; Fri, 26 May 2000 09:46:45 +0100 (BST) Message-ID: <392E39F4.738D36FC@ubiquity.net> Date: Fri, 26 May 2000 09:46:44 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] draft-rosenberg-sip-guidelines-00.txt References: <392BFE60.8BE09351@ubiquity.net> <392E04E8.9EF7B31@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Thanks for your reply Jonathan. Comments inline... Jonathan Rosenberg wrote: > Neil Deason wrote: > > > > This draft states that a probing mechanism should be defined to aid > > backwards compatibility when defining new methods. It describes the > > mechanism to be used as the UAC adding some header to a standard SIP > > request. The UAS places some information in the response if it > > understands this header (and thus the extension-method). > > > > Couldn't the OPTIONS method be used to provide such a probing mechanism > > within the standard SIP framework? The response to an OPTIONS request > > should include an Allow header entity-field that lists the supported set > > of headers, including any extension-methods. > > Well, Allow lists allowed methods, not new extensions. New extensions > are listed in the Supported header. I am not sure I see your point - the probing mechanism defined in the draft is described only in relation to new methods not extensions. But the response to an OPTIONS should include a Supported header. This may all be academic though given the proposed solution ... > Since this draft was published, there was some consensus on the list > that the response to INVITE should probably contain both Allow and > Supported headers (and possibly even Accept). The particular application > was TRANSFER; it would be nice to know once the call is set up whether > the remote side can be transferred. This would allow you to "grey out" > the transfer button on the UI, rather than having the user try and then > fail. > > This would eliminate the need for the probing mechanism, and avoid the > need for the explicit OPTIONS. > Suggested wording: > > "A 200 OK response to the initial INVITE for a call SHOULD contain the > Allow and Supported headers, and MAY contain the Accept header. These > will enable the UAC to determine the features and extensions supported > by the UAS for the duration of the call. Similarly, the initial INVITE > from the UAC SHOULD contain the Allow and Supported headers, and MAY > contain the Accept header." What if an extension method was an "outside of the call" method, so there was no preceeding INVITE. Is it sufficient just to send the new method and accept the response you get might be 405 Method Not Allowed? 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 Fri May 26 05:00:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11511 for ; Fri, 26 May 2000 05:00:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ECDA244365; Fri, 26 May 2000 04:51:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 7244F44342 for ; Fri, 26 May 2000 04:51:38 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA07201; Fri, 26 May 2000 09:58:08 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "Henning Schulzrinne" Cc: Subject: RE: [SIP] Contact in OPTIONS Date: Fri, 26 May 2000 09:58:07 +0100 Message-ID: <001901bfc6f0$82b7d680$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: <392D4842.525E30AF@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hullo, Jonathan Rosenberg wrote: > To date, OPTIONS has been one of those "outside of the call" methods > which has no impact on call state. Changing the address for routing > subsequent requests was something I thought was handled through > re-INVITE; having this also happen through OPTIONS seems to add another > thing to check for, and also means that OPTIONS now has an effect on > calls, when it didn't before. Agreed. If a Contact header in an OPTIONS request/response could affect message routing, wouldn't this imply a potential need to add a Record-Route header? Actually, that reminds me: at the Bake-Off, there was some discussion about the use of Route/Record-Route; I think the following points were raised: a) any old SIP Entity can "force" a Proxy to send a message anywhere, just by inserting a Route header; b) does Record-Route only apply to the next Request (I think that this is now confirmed by the bis draft); c) is there any way to use the Record-Route mechanism to store state. I guess a) can be solved by Authentication, or similar, but it could also be solved by c). Has there been any sort of progress/ thoughts/whatever on this at all? Also, what is the motivation behind: "It [Record-Route] is also added by any proxy that translates between TCP and UDP or vice versa." (Section 6.34.1 of May bis) 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 Fri May 26 06:15:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12034 for ; Fri, 26 May 2000 06:15:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B6F324435B; Fri, 26 May 2000 06:06:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mushroom.icoe.net (icoe-gate.icoe.att.nl [194.242.71.50]) by lists.bell-labs.com (Postfix) with ESMTP id D4DCB44342 for ; Fri, 26 May 2000 06:06:24 -0400 (EDT) Received: by mushroom.icoe.net; id MAA16763; Fri, 26 May 2000 12:14:56 +0200 (CEST) Received: from unknown(135.76.170.11) by mushroom.icoe.net via smap (4.0a) id xma016753; Fri, 26 May 00 12:14:35 +0200 Received: from blackberry (mikan.icoe.att.com [135.76.170.4]) by watermelon.icoe.att.com (Postfix) with ESMTP id B688E11581; Fri, 26 May 2000 12:14:30 +0200 (MET DST) Message-Id: <4.2.0.58.20000526120743.029a8100@watermelon.icoe.att.com> X-Sender: romeo@watermelon.icoe.att.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 26 May 2000 12:14:13 +0200 To: "Michael A. Ramalho" From: Romeo Zwart Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide Cc: Michael Thomas , James Kempf , sip@lists.bell-labs.com In-Reply-To: <4.1.20000522162311.00a3ccb0@localhost> References: <14633.37013.510735.449412@thomasm-u1.cisco.com> <200005221639.JAA13815@nasnfs.eng.sun.com> <200005221639.JAA13815@nasnfs.eng.sun.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com James/Mike/Mike, et al. At 04:36 PM 22-05-00 -0400, Michael A. Ramalho wrote: > James/Mike, > I, for one, am grateful that you two have realized that > this is the crux of the debate between you. Can we go > on now? The main disconnect in this discussion seems to be the mixing of issues. On the one hand there's talk about standardization of _services_ which is, as Mike mentioned below, unlikely to be successful. In fact, I would argue that even most "Old Word" operators realize that their strength should be in service differentation, not in locking down users into a handful of predefined features that everyone offers. On the other hand, there is the idea of having a mechanism to exchange service _profiles_. This allows service portability between service providers (whether Old or New World operators), but brings with it a lot of issues around execution control, relyability, etc. Defining a(nother) service definition language, be that based on XML or anything else, would have to take into account most if not all of the argumentation that lead to CPL. > ... [stuff yanked] ...> > However, it is *very* clear to me that in the "new world" > of web-based or web-like services (and services definition) > that standardization of anything but the most rudimentary > subscriber information or core services will not make it in > "new world" deployments. Fully agree with that. > Don't fence me in, > > Michael Ramalho > ... [more stuff yanked] ... > Romeo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 09:16:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14625 for ; Fri, 26 May 2000 09:16:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F296F4435E; Fri, 26 May 2000 09:08:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id B215744342 for ; Fri, 26 May 2000 09:07:58 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA11234; Fri, 26 May 2000 14:06:55 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA19083; Fri, 26 May 2000 15:16:03 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA16113; Fri, 26 May 2000 15:15:59 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.33]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA20456; Fri, 26 May 2000 15:15:56 +0200 (MET DST) Message-ID: <392E78D7.FD1C0F1C@ms.alcatel.fr> Date: Fri, 26 May 2000 15:15:03 +0200 From: Alberto Conte Reply-To: Alberto.Conte@ms.alcatel.fr Organization: Alcatel - Corporate Research Center X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: it,en,fr MIME-Version: 1.0 To: Lars Berggren Cc: Jonathan Rosenberg , Neil Deason , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Sorry, but I still disagree. I don't think that specifying what does it mean a port number = 0 in the INVITE message (which is at the moment not defined in the RFC 2543) is a way to make the protocol more complex. I think it is just a way to ensure implementation compatibility by specifying how this kind of message must be handled. That will never prevent to use the solution proposed by Jonathan. Alberto Lars Berggren a écrit : > > On Thu, 25 May 2000, Alberto Conte wrote: > > > Putting in hold the calle is a solution, but that increases the number of messages to > > be exchanged, requiring a re-INVITE transaction! > > > > The power of SIP is to reduce the message exchanged in case of no error. And this is > > actually a case of no-error. It should be better allowing the caller to propose its > > media request delaying only the RTP port information in the ACK. > > > > Alberto > > > > I would rather think the power of SIP is its generality, flexibility and > simplicity. A re-INVITE is a very general and powerful mechanism to > accomplish many different tasks, including yours, so why not keep it that > way instead of specifying special cases which tend to make the protocol > more complex. > > /Lars > > Lars Berggren > Intertex Data AB tel: +46-8-6282828 > Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 10:16:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16067 for ; Fri, 26 May 2000 10:16:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 39D7044379; Fri, 26 May 2000 10:08:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A5D5544376 for ; Fri, 26 May 2000 10:08:15 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA16583; Fri, 26 May 2000 10:17:31 -0400 (EDT) Message-ID: <392E8A20.F93E436E@dynamicsoft.com> Date: Fri, 26 May 2000 10:28:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alberto.Conte@ms.alcatel.fr Cc: Lars Berggren , Neil Deason , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: <392E78D7.FD1C0F1C@ms.alcatel.fr> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Alberto Conte wrote: > > Sorry, but I still disagree. > > I don't think that specifying what does it mean a port number = 0 in the INVITE > message (which is at the moment not defined in the RFC 2543) is a way to make the > protocol more complex. Unfortunately, what you are proposing to do with port=0 is different from what it means in the response. That makes it more complex. Its also not backwards compatible, since this is not supported in rfc2543. However, using the reINVITE mechanism I propose is backwards compatible. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Fri May 26 10:29:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16295 for ; Fri, 26 May 2000 10:29:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D1C04438A; Fri, 26 May 2000 10:20:50 -0400 (EDT) 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 1C74144388 for ; Fri, 26 May 2000 10:20:47 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Fri, 26 May 2000 09:25:22 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L40WY0GP; Fri, 26 May 2000 10:25:20 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LCMSPHQ4; Fri, 26 May 2000 10:25:19 -0400 Message-ID: <392E8A2D.3236F0DC@americasm01.nt.com> Date: Fri, 26 May 2000 10:29:01 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF SIP Cc: Jonathan Rosenberg , Neil Deason , Alberto.Conte@ms.alcatel.fr, Lars Berggren Subject: Re: [SIP] INVITE with incomplete SDP description References: <392D1D45.5259F3DF@ms.alcatel.fr> <392D2397.EA6AFAC8@ubiquity.net> <392D43E7.CC2F69C2@dynamicsoft.com> Content-Type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA16295 I've been following this thread with interest because we're wrestling with a similar problem. So far I like Jonathan's suggestion the best (setting "c" destination address to 0.0.0.0) because that seems to be semantically consistent with the intent, i.e., start a session with a call leg (very briefly) on hold. The only niggle is using a re-INVITE, which is a perfectly good solution in my mind, rather than the ACK from the original INVITE. I note that the third party call control draft suggests that sending the SDP in the ACK after an INVITE with no SDP content is OK, so I'm not sure why the same principal wouldn't apply here. Am I missing something? Rick Workman Nortel Networks Ottawa Jonathan Rosenberg wrote: > Another way to do it is to send the initial INVITE with the desired > media streams on hold (IP address set to 0.0.0.0). When you have > specific IP address and port information, you can do a re-INVITE, and > take the user off hold by passing an updated IP address and port in each > m line. Note that the update would not occur in an ACK, but rather in a > re-INVITE. > > -Jonathan R. > > Neil Deason wrote: > > > > Alberto Conte wrote: > > > > > Lars Berggren a écrit : > > > > > > > > > > > > > > In this case you can send an INVITE without SDP, the callee lists streams > > > > in the 200, and the ACK can contain the final SDP. This behaviour is > > > > referenced in the spec. /Lars > > > > > > > > > > Sorry Lars, I don't agree with you. > > > > > > Sending an INVITE without SDP means that the caller will be forced to choose the > > > medias exchanged in the session on the base of the ones proposed by the callee! > > > > > > This is not exactly what I want. I would like the caller able to force the callee to > > > accept its choice (or a part) of the medias, delaying only the RTP port and address > > > information. > > > > But by specifying the medias in an INVITE you don't 'force' the callee to accept the caller's > > choice. It is the opening offer in the two parties agreeing on media types. If you do not include > > the session description in the INVITE, the other party should offer it's supported media streams > > and codecs in its 1xx or 2xx response. Your UA then sends a completed session description in the > > ACK. > > > > 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 > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 May 26 10:56:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16994 for ; Fri, 26 May 2000 10:56:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 735CA44392; Fri, 26 May 2000 10:47:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by lists.bell-labs.com (Postfix) with ESMTP id 42CF044342 for ; Fri, 26 May 2000 10:47:42 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA07025; Fri, 26 May 2000 15:46:41 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id QAA13069; Fri, 26 May 2000 16:56:04 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id QAA22034; Fri, 26 May 2000 16:56:06 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.33]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id QAA00398; Fri, 26 May 2000 16:55:58 +0200 (MET DST) Message-ID: <392E9086.59510923@ms.alcatel.fr> Date: Fri, 26 May 2000 16:56:06 +0200 From: Alberto Conte Reply-To: Alberto.Conte@ms.alcatel.fr Organization: Alcatel - Corporate Research Center X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: it,en,fr MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Lars Berggren , Neil Deason , IETF SIP Subject: Re: [SIP] INVITE with incomplete SDP description References: <392E78D7.FD1C0F1C@ms.alcatel.fr> <392E8A20.F93E436E@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Jonathan Rosenberg a écrit : > > Alberto Conte wrote: > > > > Sorry, but I still disagree. > > > > I don't think that specifying what does it mean a port number = 0 in the INVITE > > message (which is at the moment not defined in the RFC 2543) is a way to make the > > protocol more complex. > > Unfortunately, what you are proposing to do with port=0 is different > from what it means in the response. That makes it more complex. Its also > not backwards compatible, since this is not supported in rfc2543. > However, using the reINVITE mechanism I propose is backwards compatible. > > -Jonathan R. > My point is: which is the behavior of a RFC2543 compliant SIP terminal when receiving an INVITE message with the format that I proposed? I don't think this is defined. I think to something like "400 Bad Request" . In such case I don't see any problem of backward compatibility. Terminals not supporting the port=0 format should always reply with that error message. Alberto _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 11:14:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17491 for ; Fri, 26 May 2000 11:14:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 75BD944376; Fri, 26 May 2000 11:05:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (unknown [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id C2EA944342 for ; Fri, 26 May 2000 11:05:50 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA20640; Fri, 26 May 2000 10:14:14 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA15738; Fri, 26 May 2000 10:14:13 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA13957; Fri, 26 May 2000 10:14:13 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA04558; Fri, 26 May 2000 10:14:12 -0500 (CDT) Message-Id: <200005261514.KAA04558@b04a24.exu.ericsson.se> Subject: Re: [SIP] Contact in OPTIONS To: jhornsby@ubiquity.net (Jo Hornsby) Date: Fri, 26 May 2000 10:14:12 -0500 (CDT) Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg), schulzrinne@cs.columbia.edu (Henning Schulzrinne), sip@lists.bell-labs.com In-Reply-To: <001901bfc6f0$82b7d680$4e34c3c1@ubiquity.co.uk> from "Jo Hornsby" at May 26, 2000 09:58:07 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >Actually, that reminds me: at the Bake-Off, there was some discussion >about the use of Route/Record-Route; I think the following points were >raised: > a) any old SIP Entity can "force" a Proxy to send a message > anywhere, just by inserting a Route header; > b) does Record-Route only apply to the next Request (I think > that this is now confirmed by the bis draft); > c) is there any way to use the Record-Route mechanism to > store state. > >I guess a) can be solved by Authentication, or similar, but it >could also be solved by c). Has there been any sort of progress/ >thoughts/whatever on this at all? Actually, I thought B was somewhat controversial; I'm surprised that it was changed without a lot of discussion on the list. Personally, I have no objection to the new behaviour; I just severely dislike the fact that it is not backwards compatible with the 2543 draft. Specifically, 2543-based call-stateful proxies (including firewalls) will break in all kinds of ways with 2543bis-based clients, if this change is finalized. Yuck. Perhaps we can add something to the message so that 2543bis based clients can tell that the "new" behavior is being used? >Also, what is the motivation behind: > "It [Record-Route] is also added by any proxy that translates > between TCP and UDP or vice versa." >(Section 6.34.1 of May bis) Presumably, this function (TCP/UDP translation) would be provided only if the clients couldn't talk to each other directly (e.g. one is TCP only, and the other is UDP only). In this case, the proxy must remain in the path to continue to provide TCP/UDP translation for the duration of the call leg. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 11:30:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18172 for ; Fri, 26 May 2000 11:30:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 369A144388; Fri, 26 May 2000 11:22:17 -0400 (EDT) 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 8A19044381 for ; Fri, 26 May 2000 11:22:14 -0400 (EDT) Received: from mr4.exu.ericsson.se (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA27431; Fri, 26 May 2000 10:30:45 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA04351; Fri, 26 May 2000 10:30:45 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14759; Fri, 26 May 2000 10:30:44 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA04625; Fri, 26 May 2000 10:30:44 -0500 (CDT) Message-Id: <200005261530.KAA04625@b04a24.exu.ericsson.se> Subject: Re: [SIP] INVITE with incomplete SDP description To: Alberto.Conte@ms.alcatel.fr Date: Fri, 26 May 2000 10:30:44 -0500 (CDT) Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg), ndeason@ubiquity.net (Neil Deason), lars@intertex.se (Lars Berggren), sip@lists.bell-labs.com (IETF SIP) In-Reply-To: <392D4F2A.9571F52F@ms.alcatel.fr> from "Alberto Conte" at May 25, 2000 06:04:58 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >Putting in hold the calle is a solution, but that increases the number of messages to >be exchanged, requiring a re-INVITE transaction! > >The power of SIP is to reduce the message exchanged in case of no error. And this is >actually a case of no-error. It should be better allowing the caller to propose its >media request delaying only the RTP port information in the ACK. I'm going to have to go along with Lars and Jonathan here. The power of SIP is in its generality. The tools defined with the protocol as it stands today are flexible enough to allow solutions to a wide variety of problems, including yours, without requiring protocol changes (and complicated exception cases in implementations) to handle special-case optimisations like the one you propose. For quite some time now, the SIP working group has been operating under the premise that generality is far superior to optimisations. It is an explicitly stated working group doctrine. I don't beleive the situation you are describing is in any way special enough to radically change our mode of operation. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 11:34:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18292 for ; Fri, 26 May 2000 11:34:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBDEA443A6; Fri, 26 May 2000 11:25:32 -0400 (EDT) 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 670F7443A2 for ; Fri, 26 May 2000 11:25:30 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri May 26 11:32:23 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1DDD044344; Fri, 26 May 2000 11:19:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id E8E5B44341 for ; Fri, 26 May 2000 11:19:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E7DC652C4; Fri, 26 May 2000 11:19:33 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1AE6A52B6 for ; Fri, 26 May 2000 11:19:30 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri May 26 11:18:54 EDT 2000 Received: from imr1.ericy.com ([208.237.135.240]) by dusty; Fri May 26 11:18:54 EDT 2000 Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA22493; Fri, 26 May 2000 10:18:51 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA17853; Fri, 26 May 2000 10:18:51 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14208; Fri, 26 May 2000 10:18:50 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA04576; Fri, 26 May 2000 10:18:50 -0500 (CDT) Message-Id: <200005261518.KAA04576@b04a24.exu.ericsson.se> Subject: Re: [SIP] Error in "SIP Call Control Services"? - was [SIP]Multimedia Conferencing To: hyongsop@research.telcordia.com (Hyong Sop Shim) Date: Fri, 26 May 2000 10:18:49 -0500 (CDT) Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg), sip@lists.research.bell-labs.com In-Reply-To: <392D9F75.278396A7@research.telcordia.com> from "Hyong Sop Shim" at May 25, 2000 05:47:33 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >In Figure 4 in 8.3 Add Party during Add Party, D, acting on the untriggered INVITE >message from B, sends an INVITE message to A, "INV A Also:A, B." But, shouldn't >this INVITE message from D be "INV A Also:B ReqBy:B" instead? This draft has expired; I don't beleive a new version will be issued. The way forward with call-control which will probably be adopted is outlined in draft-campbell-sip-cc-framework-00.txt (which is being updated to bring it in line with draft-rosenberg-sip-guidelines-00.txt). An example of the modular approach espoused in this draft is presented in draft-sparks-sip-cc-transfer-00.txt (which will probably be changing to be more general in its next release). -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 11:49:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18590 for ; Fri, 26 May 2000 11:49:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0817144391; Fri, 26 May 2000 11:41:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id EE4FC44342 for ; Fri, 26 May 2000 11:40:59 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA20282; Fri, 26 May 2000 16:47:31 +0100 (BST) From: "Jo Hornsby" To: Subject: RE: [SIP] Contact in OPTIONS Date: Fri, 26 May 2000 16:47:31 +0100 Message-ID: <002a01bfc729$b3ce1fc0$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: <200005261514.KAA04558@b04a24.exu.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > >Also, what is the motivation behind: > > "It [Record-Route] is also added by any proxy that translates > > between TCP and UDP or vice versa." > >(Section 6.34.1 of May bis) > > Presumably, this function (TCP/UDP translation) would be provided > only if the clients couldn't talk to each other directly (e.g. > one is TCP only, and the other is UDP only). In this case, the > proxy must remain in the path to continue to provide TCP/UDP > translation for the duration of the call leg. Yes. A colleague (hi James!) suggested much the same. It does potentially seem to be a little bit of a shame, however; I can imagine a chain of proxies presenting a path that alternates between UDP/TCP with User Agents talking UDP (or TCP) at either end. Of course, I'm at a loss for anything better. Ah well, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 12:10:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19125 for ; Fri, 26 May 2000 12:10:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D28AD44386; Fri, 26 May 2000 12:01:32 -0400 (EDT) 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 6A96C44342 for ; Fri, 26 May 2000 12:01:30 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 26 12:08:44 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6776144344; Fri, 26 May 2000 11:55:34 -0400 (EDT) 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 1BF6D44341 for ; Fri, 26 May 2000 11:55:34 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA00738; Fri, 26 May 2000 10:55:31 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA00703; Fri, 26 May 2000 10:55:29 -0500 Message-ID: <392E9E6F.C2AD1B9C@lucent.com> Date: Fri, 26 May 2000 10:55:27 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <200005261514.KAA04558@b04a24.exu.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Adam B. Roach" wrote: > > >Actually, that reminds me: at the Bake-Off, there was some discussion > >about the use of Route/Record-Route; I think the following points > >were raised: > > a) any old SIP Entity can "force" a Proxy to send a message > > anywhere, just by inserting a Route header; > > b) does Record-Route only apply to the next Request (I think > > that this is now confirmed by the bis draft); > > c) is there any way to use the Record-Route mechanism to > > store state. [...] > Actually, I thought B was somewhat controversial; I'm surprised > that it was changed without a lot of discussion on the list. > Personally, I have no objection to the new behaviour; I just > severely dislike the fact that it is not backwards compatible > with the 2543 draft. Specifically, 2543-based call-stateful > proxies (including firewalls) will break in all kinds of ways > with 2543bis-based clients, if this change is finalized. Yuck. I agree with Adam here. RFC2543bis does state that this "...field is added to a request by any proxy that insists on being in the path of the next request for the same call leg". I liked the RFC2543 behavior better when the field was added to a request by any proxy that insists on being in the path of _subsequent_ requests. This will break existing proxy behavior. I am sure there are reasons why the per-request model was chosen in RFC2543bis? Could someone refresh my memory with the most pressing ones? Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 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 May 26 13:28:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20863 for ; Fri, 26 May 2000 13:27:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 858144437C; Fri, 26 May 2000 13:19:13 -0400 (EDT) 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 D257344342 for ; Fri, 26 May 2000 13:19:10 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id MAA13940; Fri, 26 May 2000 12:27:38 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id MAA14879; Fri, 26 May 2000 12:27:36 -0500 (CDT) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA20462; Fri, 26 May 2000 12:25:55 -0500 (CDT) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id MAA04870; Fri, 26 May 2000 12:25:55 -0500 (CDT) Message-Id: <200005261725.MAA04870@b04a24.exu.ericsson.se> Subject: Re: [SIP] Contact in OPTIONS To: vkg@lucent.com Date: Fri, 26 May 2000 12:25:54 -0500 (CDT) Cc: sip@lists.bell-labs.com In-Reply-To: <392E9E6F.C2AD1B9C@lucent.com> from "Vijay K. Gurbani" at May 26, 2000 10:55:27 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >RFC2543bis does state that this "...field is >added to a request by any proxy that insists on being in the path of >the next request for the same call leg". I liked the RFC2543 behavior >better when the field was added to a request by any proxy that insists >on being in the path of _subsequent_ requests. This just jogged my memory about something else that might need to be addressed in the case that "Record-Route" applies to only the next transaction, somewhat akin to re-INVITE glare. We need to closely examine the implications of requests crossing on the wire; under these circumstances, the "next" transaction is something of an ambiguous concept. I beleive this could lead to some pretty spectacular headaches. In particular, think of two clients with two proxies between them. If requests cross between the two proxies... my head hurts thinking about trying to reconcile the record-route state of all four nodes. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri May 26 14:12:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22018 for ; Fri, 26 May 2000 14:12:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA1B944383; Fri, 26 May 2000 14:03:31 -0400 (EDT) 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 7DD3744342 for ; Fri, 26 May 2000 14:03:29 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 26 14:11:39 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 4965344344; Fri, 26 May 2000 13:58:30 -0400 (EDT) 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 17F8744341 for ; Fri, 26 May 2000 13:58:30 -0400 (EDT) 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 NAA04254; Fri, 26 May 2000 13:58:29 -0400 (EDT) Message-ID: <392EBB45.83589477@cs.columbia.edu> Date: Fri, 26 May 2000 13:58:29 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: "Adam B. Roach" Cc: Jo Hornsby , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <200005261514.KAA04558@b04a24.exu.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Adam B. Roach wrote: > > >Actually, that reminds me: at the Bake-Off, there was some discussion > >about the use of Route/Record-Route; I think the following points were > >raised: > > a) any old SIP Entity can "force" a Proxy to send a message > > anywhere, just by inserting a Route header; > > b) does Record-Route only apply to the next Request (I think > > that this is now confirmed by the bis draft); > > c) is there any way to use the Record-Route mechanism to > > store state. > > > >I guess a) can be solved by Authentication, or similar, but it > >could also be solved by c). Has there been any sort of progress/ > >thoughts/whatever on this at all? > > Actually, I thought B was somewhat controversial; I'm surprised > that it was changed without a lot of discussion on the list. > Personally, I have no objection to the new behaviour; I just > severely dislike the fact that it is not backwards compatible > with the 2543 draft. Specifically, 2543-based call-stateful > proxies (including firewalls) will break in all kinds of ways > with 2543bis-based clients, if this change is finalized. Yuck. Consider the inclusion in 2543bis as an incentive to reach closure. It might help to provide real examples where Record-Route is essential and whether they'd be better off with next-request or rest-of-call semantics. Firewalls clearly fall into the rest-of-call class. > > Perhaps we can add something to the message so that 2543bis based > clients can tell that the "new" behavior is being used? > > >Also, what is the motivation behind: > > "It [Record-Route] is also added by any proxy that translates > > between TCP and UDP or vice versa." > >(Section 6.34.1 of May bis) > > Presumably, this function (TCP/UDP translation) would be provided > only if the clients couldn't talk to each other directly (e.g. > one is TCP only, and the other is UDP only). In this case, the > proxy must remain in the path to continue to provide TCP/UDP > translation for the duration of the call leg. Since then, some additional discussion seems to indicate that things get a lot easier if we require UAs to speak UDP as the lingua franca. Otherwise, we can't satisfy the goal of simply plugging in a bunch of SIP phones and setting up calls, without a 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 May 26 14:42:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22755 for ; Fri, 26 May 2000 14:42:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C98A44396; Fri, 26 May 2000 14:33:32 -0400 (EDT) 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 D3EC744342 for ; Fri, 26 May 2000 14:33:29 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri May 26 14:41:13 EDT 2000 Received: by lists.bell-labs.com (Postfix) id DD35544344; Fri, 26 May 2000 14:28:03 -0400 (EDT) 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 91B0A44341 for ; Fri, 26 May 2000 14:28:03 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA16063; Fri, 26 May 2000 13:27:59 -0500 Cc: "Adam B. Roach" , Jonathan Rosenberg , sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA16042; Fri, 26 May 2000 13:27:51 -0500 Message-ID: <392EC225.56C19C77@lucent.com> Date: Fri, 26 May 2000 13:27:49 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Original-CC: "Adam B. Roach" , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <200005261514.KAA04558@b04a24.exu.ericsson.se> <392EBB45.83589477@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: [...] > Consider the inclusion in 2543bis as an incentive to reach closure. It > might help to provide real examples where Record-Route is essential > and whether they'd be better off with next-request or rest-of-call > semantics. Firewalls clearly fall into the rest-of-call class. [...] As do call-model mapping proxies; i.e. SIP proxies which provide services based on a mapping of foreign call models. Some of the work we have done in this domain takes advantage of the "rest-of-call" semantics by having the proxy inject a Record-Route in the first INVITE message and being guaranteed that subsequent requests (ACK, CANCEL or BYE) and responses (especially 200 OK) will come through it. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 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 May 26 20:23:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28382 for ; Fri, 26 May 2000 20:23:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0086844357; Fri, 26 May 2000 20:14:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [207.104.210.242]) by lists.bell-labs.com (Postfix) with ESMTP id 2B9C244342 for ; Fri, 26 May 2000 20:14:56 -0400 (EDT) Received: by exchange.netrue.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 May 2000 17:25:27 -0700 Message-ID: From: Tricia Wang To: sip@lists.bell-labs.com Date: Fri, 26 May 2000 17:25:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP Application Server Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, All I am writing a design document for a SIP network Is Application Server "a kind of" Proxy Server or Redirect Server or Neither? (Application Server will provide some services) Thank you so much Tricia _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat May 27 00:51:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02793 for ; Sat, 27 May 2000 00:51:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B0B9A4435C; Sat, 27 May 2000 00:42:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tapti.hss.hns.com (tapti.hss.hns.com [139.85.242.19]) by lists.bell-labs.com (Postfix) with ESMTP id E5C8944342 for ; Sat, 27 May 2000 00:42:32 -0400 (EDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA06503; Sat, 27 May 2000 11:05:04 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568EC.001B5E54 ; Sat, 27 May 2000 10:28:56 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Tricia Wang Cc: sip@lists.bell-labs.com Message-ID: <652568EC.001B5E2D.00@sampark.hss.hns.com> Date: Sat, 27 May 2000 10:28:55 +0530 Subject: Re: [SIP] SIP Application Server 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com My understanding of an 'Application Server' is that it is a logical entity, that provides services to network entities. What services depends on what Applications are executing in this App. Server and what entity is being interfaced with. If you now talk about the SIP Domain, whether the Application Server is colocated 'physically' with a Proxy server or some other SIP entity is an implementation issue. But my guess would be that a SIP Proxy is likely to interface with your logical Application Server, since it would usually be providing the most services. That does not however imply that the App. Server is necessarily sitting on top of a proxy /redirect. In short, as far as I know, Application Server is a logical entity that *can* be physically colocated with your SIP Proxy, if you so wish - or it can be a separate Physical server with some means of communication with all entities requesting services (the entities can be Proxies, terminal , or any other such device) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Tricia Wang on 05/27/2000 05:55:26 AM To: sip@lists.bell-labs.com cc: Subject: [SIP] SIP Application Server Hi, All I am writing a design document for a SIP network Is Application Server "a kind of" Proxy Server or Redirect Server or Neither? (Application Server will provide some services) Thank you so much Tricia _______________________________________________ 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 Sat May 27 23:13:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25096 for ; Sat, 27 May 2000 23:13:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 867C44433D; Sat, 27 May 2000 23:05:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0B5394433B for ; Sat, 27 May 2000 23:05:02 -0400 (EDT) Received: from dynamicsoft.com (1Cust153.tnt2.freehold.nj.da.uu.net [63.17.114.153]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA19329; Sat, 27 May 2000 23:14:44 -0400 (EDT) Message-ID: <393091D1.49F4B1D4@dynamicsoft.com> Date: Sat, 27 May 2000 23:26:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: Henning Schulzrinne , "Adam B. Roach" , sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <200005261514.KAA04558@b04a24.exu.ericsson.se> <392EBB45.83589477@cs.columbia.edu> <392EC225.56C19C77@lucent.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Another application I am aware of for record-routing, generation of call detail records for proxies fronting a gateway, also requires it to see all requests. Seems like consensus so far to keep the current semantics.... anyone object? Thanks, Jonathan R. "Vijay K. Gurbani" wrote: > > Henning Schulzrinne wrote: > [...] > > Consider the inclusion in 2543bis as an incentive to reach closure. It > > might help to provide real examples where Record-Route is essential > > and whether they'd be better off with next-request or rest-of-call > > semantics. Firewalls clearly fall into the rest-of-call class. > [...] > > As do call-model mapping proxies; i.e. SIP proxies which provide > services based on a mapping of foreign call models. Some of the work > we have done in this domain takes advantage of the "rest-of-call" > semantics by having the proxy inject a Record-Route in the first INVITE > message and being guaranteed that subsequent requests (ACK, CANCEL or > BYE) and responses (especially 200 OK) will come through it. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > IN Architecture and Internet Software Group > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Sun May 28 01:36:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00456 for ; Sun, 28 May 2000 01:36:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5FBBB4433B; Sun, 28 May 2000 01:27:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C836644338 for ; Sun, 28 May 2000 01:27:41 -0400 (EDT) Received: from dynamicsoft.com (1Cust153.tnt2.freehold.nj.da.uu.net [63.17.114.153]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA19383; Sun, 28 May 2000 01:36:29 -0400 (EDT) Message-ID: <3930B309.2DD20E61@dynamicsoft.com> Date: Sun, 28 May 2000 01:47:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: "Adam B. Roach" , Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <200005261514.KAA04558@b04a24.exu.ericsson.se> <392EBB45.83589477@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > Presumably, this function (TCP/UDP translation) would be provided > > only if the clients couldn't talk to each other directly (e.g. > > one is TCP only, and the other is UDP only). In this case, the > > proxy must remain in the path to continue to provide TCP/UDP > > translation for the duration of the call leg. > > Since then, some additional discussion seems to indicate that things get > a lot easier if we require UAs to speak UDP as the lingua franca. > Otherwise, we can't satisfy the goal of simply plugging in a bunch of > SIP phones and setting up calls, without a proxy. To be specific, the proposal is that UDP support in UA transition from SHOULD to MUST, so that: 1. UAs SHOULD support TCP, MUST support UDP 2. proxies MUST support TCP and UDP The transport parameter in the Contact and Record-Route headers then becomes the preferential choice; if not supported, you can always fall back to UDP. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Sun May 28 01:49:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01703 for ; Sun, 28 May 2000 01:49:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ADE574433E; Sun, 28 May 2000 01:41:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3EC2C4433D for ; Sun, 28 May 2000 01:41:04 -0400 (EDT) Received: from dynamicsoft.com (1Cust153.tnt2.freehold.nj.da.uu.net [63.17.114.153]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA19395; Sun, 28 May 2000 01:47:24 -0400 (EDT) Message-ID: <3930B598.1DBE4F91@dynamicsoft.com> Date: Sun, 28 May 2000 01:58:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] draft-rosenberg-sip-guidelines-00.txt References: <392BFE60.8BE09351@ubiquity.net> <392E04E8.9EF7B31@dynamicsoft.com> <392E39F4.738D36FC@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > > > Couldn't the OPTIONS method be used to provide such a probing mechanism > > > within the standard SIP framework? The response to an OPTIONS request > > > should include an Allow header entity-field that lists the supported set > > > of headers, including any extension-methods. > > > > Well, Allow lists allowed methods, not new extensions. New extensions > > are listed in the Supported header. > > I am not sure I see your point - the probing mechanism defined in the draft is > described only in relation to new methods not extensions. Right, thats my point. Your comment was: > The response to an OPTIONS request > should include an Allow header entity-field that lists the supported set > of headers, including any extension-methods. which was that the Allow header should list supported headers. It does not. It only lists allowed methods. > What if an extension method was an "outside of the call" method, so there was > no preceeding INVITE. Is it sufficient just to send the new method and accept > the response you get might be 405 Method Not Allowed? Of course. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Sun May 28 04:05:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06196 for ; Sun, 28 May 2000 04:05:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A116C4433B; Sun, 28 May 2000 03:56:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id F166244338 for ; Sun, 28 May 2000 03:56:09 -0400 (EDT) Received: from dynamicsoft.com (1Cust153.tnt2.freehold.nj.da.uu.net [63.17.114.153]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA00189 for ; Sun, 28 May 2000 04:06:06 -0400 (EDT) Message-ID: <3930D614.972F8D1A@dynamicsoft.com> Date: Sun, 28 May 2000 04:17:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] wg last call on reliable provisional responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Folks, I've just submitted an updated version of the I-D on "Reliability of Provisional Responses in SIP". Until it appears in the archives, you can find a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-sip-100rel-01.txt The changes since the last version are: 1. CANCEL disallowed for PRACK 2. Require allowed in requests for this extension 3. option tag changed from org.ietf.sip.100rel to 100rel 4. Proxy-Require disallowed 5. discussion of sending final responses to original request before all reliable provisional responses have been received (its allowed) 6. clarifications Once this draft appears in the archives, a two week working group last call will begin. At the end of that last call, if no comments are heard, the document will be sent to IESG for consideration as proposed standard. Thanks, Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 29 05:44:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28763 for ; Mon, 29 May 2000 05:44:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E925544339; Mon, 29 May 2000 05:35:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 74BA144338 for ; Mon, 29 May 2000 05:35:36 -0400 (EDT) Date: Mon, 29 May 2000 11:46:21 +0200 (CEST) From: Lars Berggren To: Henning Schulzrinne Cc: "Adam B. Roach" , Jo Hornsby , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS In-Reply-To: <392EBB45.83589477@cs.columbia.edu> Message-ID: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Fri, 26 May 2000, Henning Schulzrinne wrote: > Adam B. Roach wrote: > > > > Actually, I thought B was somewhat controversial; I'm surprised > > that it was changed without a lot of discussion on the list. > > Personally, I have no objection to the new behaviour; I just > > severely dislike the fact that it is not backwards compatible > > with the 2543 draft. Specifically, 2543-based call-stateful > > proxies (including firewalls) will break in all kinds of ways > > with 2543bis-based clients, if this change is finalized. Yuck. > > Consider the inclusion in 2543bis as an incentive to reach closure. It > might help to provide real examples where Record-Route is essential and > whether they'd be better off with next-request or rest-of-call > semantics. Firewalls clearly fall into the rest-of-call class. > I recall an earlier discussion on the list where arguements were made that the next-request behaviour would help a UA that crashes, reboots and receives a re-INVITE for the call. The INVITE is designed so that it carries the information necessary to join the session regardless of whether you know about previous requests or not. The next-request mechanism would adhere to that design decision. Also, in favour of the next-request behaviour, if the route can be changed as the call progresses, I guess it can be useful. A proxy might want to step out of the signalling path for example, but I don't have any real world example on this. However I also dislike the fact that the next-request mechanism is not backwards compatible. /Lars Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 29 09:35:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00340 for ; Mon, 29 May 2000 09:35:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A23A4433B; Mon, 29 May 2000 09:26:13 -0400 (EDT) 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 9494E44338 for ; Mon, 29 May 2000 09:26:10 -0400 (EDT) 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 JAA12200; Mon, 29 May 2000 09:35:02 -0400 (EDT) Message-ID: <39327206.F1E3AD95@cs.columbia.edu> Date: Mon, 29 May 2000 09:35:02 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Lars Berggren Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Lars Berggren wrote: > > On Fri, 26 May 2000, Henning Schulzrinne wrote: > > Adam B. Roach wrote: > > > > > > Actually, I thought B was somewhat controversial; I'm surprised > > > that it was changed without a lot of discussion on the list. > > > Personally, I have no objection to the new behaviour; I just > > > severely dislike the fact that it is not backwards compatible > > > with the 2543 draft. Specifically, 2543-based call-stateful > > > proxies (including firewalls) will break in all kinds of ways > > > with 2543bis-based clients, if this change is finalized. Yuck. > > > > Consider the inclusion in 2543bis as an incentive to reach closure. It > > might help to provide real examples where Record-Route is essential and > > whether they'd be better off with next-request or rest-of-call > > semantics. Firewalls clearly fall into the rest-of-call class. > > > > I recall an earlier discussion on the list where arguements were made that > the next-request behaviour would help a UA that crashes, reboots and > receives a re-INVITE for the call. The INVITE is designed so that it > carries the information necessary to join the session regardless of > whether you know about previous requests or not. The next-request > mechanism would adhere to that design decision. > > Also, in favour of the next-request behaviour, if the route can be changed > as the call progresses, I guess it can be useful. A proxy might want to > step out of the signalling path for example, but I don't have any real > world example on this. > > However I also dislike the fact that the next-request mechanism is not > backwards compatible. One possibility to increase robustness in the face of restarts might be to have proxies insert Record-Route in every request. That way, the rebooted component will still get the right information. This would seem to be backward compatible. In this model, once a proxy adds itself to the route, it cannot delete itself, i.e., *not* including does not imply dropping out. Also, changing RR entries (for example, changing the maddr part) could not be guaranteed to be respected by the other side. Would this work? -- 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 May 29 13:29:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01878 for ; Mon, 29 May 2000 13:29:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8BE5444338; Mon, 29 May 2000 13:20:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by lists.bell-labs.com (Postfix) with ESMTP id 88AFA44337 for ; Mon, 29 May 2000 13:20:38 -0400 (EDT) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA12448; Mon, 29 May 2000 19:28:59 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([218.1.68.147]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA05238; Mon, 29 May 2000 19:26:26 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2448.0) id ; Mon, 29 May 2000 19:31:32 +0200 Message-ID: <679076A067F2D211A8F70090274481B815159B@LNN201E> From: Samandi Sami To: "'archow@hss.hns.com'" , Tricia Wang Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP Application Server Date: Mon, 29 May 2000 19:31:14 +0200 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hello, Is there any document (or work) out there describing the distribution of logic between a feature server (or application server) and the underlying network server asking for the services. It is true this is an implementation issue but it is also true that this split of the roles between a SIP application server and a SIP proxy server is similar to the IN architecture where the SSP handles the call control and the SCP the service control. Is it then logical to think about an implementation like the following : - The network server is a call stateful proxy (holding the state of a call between the INVITE and the BYE). This SIP proxy forward requests to the application server. This proxy server goes stateful and proxy requests only when needed (for instance when the end user has subscribed to predefined services). - The application server will behave per call basis whether as a redirect server (to provide routing services) or as a UAS when media services are needed (IVR, ...). I am not sure whether this equipment should also proxy the request ?. - The goal here is not to involve the application server for the whole duration of the call but only when needed and this means telling the application server what's state of the call that triggered the call of the service. For instance, A call B, but B is busy, the Proxy server of B receives a 486 and then sends an INVITE to the feature server asking what to do. How to tell the application server that the user is busy (the equivalent of the DP Terminal busy of the IN) ? Should this be done in a proprietary way ? Could someone comment on this please even if it seems straightforward and maybe a quite high level views. Thank you Sami -----Original Message----- From: archow@hss.hns.com [SMTP:archow@hss.hns.com] Sent: samedi 27 mai 2000 06:59 To: Tricia Wang Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server My understanding of an 'Application Server' is that it is a logical entity, that provides services to network entities. What services depends on what Applications are executing in this App. Server and what entity is being interfaced with. If you now talk about the SIP Domain, whether the Application Server is colocated 'physically' with a Proxy server or some other SIP entity is an implementation issue. But my guess would be that a SIP Proxy is likely to interface with your logical Application Server, since it would usually be providing the most services. That does not however imply that the App. Server is necessarily sitting on top of a proxy /redirect. In short, as far as I know, Application Server is a logical entity that *can* be physically colocated with your SIP Proxy, if you so wish - or it can be a separate Physical server with some means of communication with all entities requesting services (the entities can be Proxies, terminal , or any other such device) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Tricia Wang on 05/27/2000 05:55:26 AM To: sip@lists.bell-labs.com cc: Subject: [SIP] SIP Application Server Hi, All I am writing a design document for a SIP network Is Application Server "a kind of" Proxy Server or Redirect Server or Neither? (Application Server will provide some services) Thank you so much Tricia _______________________________________________ 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 May 29 15:00:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02774 for ; Mon, 29 May 2000 15:00:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C0F444341; Mon, 29 May 2000 14:51:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lists.bell-labs.com (Postfix) with ESMTP id 97C7644337 for ; Mon, 29 May 2000 14:51:04 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 29 May 2000 14:57:36 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 29 May 2000 14:57:36 -0400 Message-ID: From: "Tom-PT Taylor" To: "'Lars Berggren'" , Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Contact in OPTIONS Date: Mon, 29 May 2000 14:57:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC99F.C0CF2B2E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 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_01BFC99F.C0CF2B2E Content-Type: text/plain One example of when a proxy might want to step out of the signalling path is that of overlap outpulsing in a gateway situation. The proxy might stay in the path until it had determined that all digits had been collected. At that point, having translated the digits to an ultimate destination, it could retire from the call. > -----Original Message----- > From: Lars Berggren [SMTP:lars@intertex.se] > Sent: Monday, May 29, 2000 5:46 AM > To: Henning Schulzrinne > Cc: Adam B. Roach; Jo Hornsby; Jonathan Rosenberg; > sip@lists.bell-labs.com > Subject: Re: [SIP] Contact in OPTIONS > > On Fri, 26 May 2000, Henning Schulzrinne wrote: > > Adam B. Roach wrote: > > > > > > Actually, I thought B was somewhat controversial; I'm surprised > > > that it was changed without a lot of discussion on the list. > > > Personally, I have no objection to the new behaviour; I just > > > severely dislike the fact that it is not backwards compatible > > > with the 2543 draft. Specifically, 2543-based call-stateful > > > proxies (including firewalls) will break in all kinds of ways > > > with 2543bis-based clients, if this change is finalized. Yuck. > > > > Consider the inclusion in 2543bis as an incentive to reach closure. It > > might help to provide real examples where Record-Route is essential and > > whether they'd be better off with next-request or rest-of-call > > semantics. Firewalls clearly fall into the rest-of-call class. > > > > I recall an earlier discussion on the list where arguements were made that > the next-request behaviour would help a UA that crashes, reboots and > receives a re-INVITE for the call. The INVITE is designed so that it > carries the information necessary to join the session regardless of > whether you know about previous requests or not. The next-request > mechanism would adhere to that design decision. > > Also, in favour of the next-request behaviour, if the route can be changed > as the call progresses, I guess it can be useful. A proxy might want to > step out of the signalling path for example, but I don't have any real > world example on this. > > However I also dislike the fact that the next-request mechanism is not > backwards compatible. > > /Lars > > Lars Berggren > Intertex Data AB tel: +46-8-6282828 > Sundbyberg, Sweden fax: +46-8-6286414 > > ------_=_NextPart_001_01BFC99F.C0CF2B2E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] Contact in OPTIONS

One example of when = a proxy might want to step out of the signalling path is that of = overlap outpulsing in a gateway situation.  The proxy might stay = in the path until it had determined that all digits had been = collected.  At that point, having translated the digits to an = ultimate destination, it could retire from the call. 

    -----Original Message-----
    From:   Lars Berggren [SMTP:lars@intertex.se]
    Sent:   Monday, May 29, 2000 5:46 AM
    To:     Henning Schulzrinne
    Cc:     Adam B. Roach; Jo Hornsby; Jonathan Rosenberg; = sip@lists.bell-labs.com
    Subject:       = Re: [SIP] Contact in OPTIONS

    On Fri, 26 May 2000, Henning = Schulzrinne wrote:
    > Adam B. Roach wrote:
    > >
    > > Actually, I thought B was = somewhat controversial; I'm surprised
    > > that it was changed without = a lot of discussion on the list.
    > > Personally, I have no = objection to the new behaviour; I just
    > > severely dislike the fact = that it is not backwards compatible
    > > with the 2543 draft. = Specifically, 2543-based call-stateful
    > > proxies (including = firewalls) will break in all kinds of ways
    > > with 2543bis-based clients, = if this change is finalized. Yuck.
    >
    > Consider the inclusion in = 2543bis as an incentive to reach closure. It
    > might help to provide real = examples where Record-Route is essential and
    > whether they'd be better off = with next-request or rest-of-call
    > semantics. Firewalls clearly = fall into the rest-of-call class.
    >

    I recall an earlier discussion on the = list where arguements were made that
    the next-request behaviour would help = a UA that crashes, reboots and
    receives a re-INVITE for the call. = The INVITE is designed so that it
    carries the information necessary to = join the session regardless of
    whether you know about previous = requests or not. The next-request
    mechanism would adhere to that design = decision.

    Also, in favour of the next-request = behaviour, if the route can be changed
    as the call progresses, I guess it = can be useful. A proxy might want to
    step out of the signalling path for = example, but I don't have any real
    world example on this.

    However I also dislike the fact that = the next-request mechanism is not
    backwards compatible.

    /Lars

    Lars = Berggren       <mailto:lars.berggren@intertex.= se>
    Intertex Data AB    = tel: +46-8-6282828
    Sundbyberg, Sweden  fax: = +46-8-6286414


------_=_NextPart_001_01BFC99F.C0CF2B2E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 29 16:22:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03615 for ; Mon, 29 May 2000 16:22:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 334D744338; Mon, 29 May 2000 16:13:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from avmail.smithmicro.com (avmail.smithmicro.com [209.218.67.201]) by lists.bell-labs.com (Postfix) with ESMTP id 9810F44337 for ; Mon, 29 May 2000 16:13:38 -0400 (EDT) Received: by AVMAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 29 May 2000 13:22:16 -0700 Received: from plong (adsl-32.statton.austx.uSOLnet.net [63.80.75.161]) by avmail.smithmicro.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LQ4RTKM4; Mon, 29 May 2000 13:22:06 -0700 From: Plong@smithmicro.com To: sip@lists.bell-labs.com Date: Mon, 29 May 2000 15:15:04 -0500 Message-ID: <001001bfc9aa$941216e0$6701a8c0@plong> 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] Basic questions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello, all. Just starting with SIP, but I already have a few basic questions regarding the RFC. Since this is my first query, let me know if these questions should be posted elsewhere or I have otherwise violated some other rule of etiquette. - "...SIP...is...for...sessions with one or more participants." - How can there be a session with only one participant? A session is defined elsewhere as comprising one or more RTP sessions, which implies a sender and a receiver, or two participants. Should the sentence have been written as "...with two or more participants?" - "...the H.245 [8] gateway and user address and then use H.225.0 [9] to establish the call." - What is meant by an "H.245 gateway address" and an "H.245 user address?" There is no such thing. I assume that the author is referring to the H.323 call-signaling addresses of a gateway and endpoint. There is an H.245 control-protocol address, but if a separate H.245 channel is even used, the address is conveyed during call establishment and not before. - The word, "program,: is used throughout the RFC. Is this any functional entity regardless of implementation and not exclusively a "software program?" - "Outbound proxy" - Is there also such a thing as an inbound proxy? - Regarding UA, UAC, and UAS, can this change for an entity on a per-call basis? Can this change for an entity during a call? - "Servers are either proxy, redirect or user agent servers or registrars." - I have also seen references to "location servers" and "SIP servers." Is a location server the same thing as a redirect server? Is "SIP server" just a general reference to servers in "SIPdom?" - Is "server" only a role played by an entity in a single request-response dialogue, or are some entities always servers or always clients or always both? Paul Long Smith micro Software, Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon May 29 22:04:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06614 for ; Mon, 29 May 2000 22:04:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8502C44338; Mon, 29 May 2000 21:55:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 11FCD44337 for ; Mon, 29 May 2000 21:55:28 -0400 (EDT) Received: from dynamicsoft.com (1Cust94.tnt5.freehold.nj.da.uu.net [63.36.113.94]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00671; Mon, 29 May 2000 22:05:36 -0400 (EDT) Message-ID: <393324A7.92C23B65@dynamicsoft.com> Date: Mon, 29 May 2000 22:17:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Lars Berggren , sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <39327206.F1E3AD95@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > I recall an earlier discussion on the list where arguements were made that > > the next-request behaviour would help a UA that crashes, reboots and > > receives a re-INVITE for the call. The INVITE is designed so that it > > carries the information necessary to join the session regardless of > > whether you know about previous requests or not. The next-request > > mechanism would adhere to that design decision. > > > > Also, in favour of the next-request behaviour, if the route can be changed > > as the call progresses, I guess it can be useful. A proxy might want to > > step out of the signalling path for example, but I don't have any real > > world example on this. > > > > However I also dislike the fact that the next-request mechanism is not > > backwards compatible. > > One possibility to increase robustness in the face of restarts might be > to have proxies insert Record-Route in every request. That way, the > rebooted component will still get the right information. This would seem > to be backward compatible. In this model, once a proxy adds itself to > the route, it cannot delete itself, i.e., *not* including does not imply > dropping out. Also, changing RR entries (for example, changing the maddr > part) could not be guaranteed to be respected by the other side. > > Would this work? This definitely works. Basically, what it means is that so long as a UA has state for the call, it keeps the original route and does not try to update. If, however, it crashes and restarts, it uses whatever it gets in the request. This would allow it to do a partial reconstruction of the route - "better than nothing" kind of thing, with increasing performance as this feature is spread. In addition to this, we can define an explicit "remove me" record-route entry. Something like: Remove-Route: ;remove=true Proxies would add this when they want out. A UA not understanding this will ignore out continue to use the old route, but a new UA would know that this means to remove it from the Route in the next request. I think this is also backwards compatible. Both of these mechanisms combined (remove-route and adding record-route for mid-call messages) has the desired result of being backwards compatible, providing for restarts after crashes, and allowing proxies to remove themselves during a call. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 29 22:07:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06628 for ; Mon, 29 May 2000 22:07:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E54BB44352; Mon, 29 May 2000 21:57:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6BDB14434F for ; Mon, 29 May 2000 21:57:54 -0400 (EDT) Received: from dynamicsoft.com (1Cust94.tnt5.freehold.nj.da.uu.net [63.36.113.94]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00679; Mon, 29 May 2000 22:08:04 -0400 (EDT) Message-ID: <3933253B.8E3EA088@dynamicsoft.com> Date: Mon, 29 May 2000 22:19:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Cc: "'Lars Berggren'" , Henning Schulzrinne , sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Tom-PT Taylor wrote: > > One example of when a proxy might want to step out of the signalling > path is that of overlap outpulsing in a gateway situation. The proxy > might stay in the path until it had determined that all digits had > been collected. At that point, having translated the digits to an > ultimate destination, it could retire from the call. Careful here; the way overlap is currently designed, the proxy would not have any choice about dropping out or staying in until the call completes. Record-Route takes effect only after the 200 OK. Thus, in your example, the proxy can elect to receive all of the overlap digits and then "drop out" by simply never inserting record-route in the first place. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 29 23:07:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07899 for ; Mon, 29 May 2000 23:07:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9D9954434E; Mon, 29 May 2000 22:58:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3074644337 for ; Mon, 29 May 2000 22:58:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust94.tnt5.freehold.nj.da.uu.net [63.36.113.94]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00755; Mon, 29 May 2000 23:08:14 -0400 (EDT) Message-ID: <39333355.5BB5B119@dynamicsoft.com> Date: Mon, 29 May 2000 23:19:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Samandi Sami Cc: "'archow@hss.hns.com'" , Tricia Wang , sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: <679076A067F2D211A8F70090274481B815159B@LNN201E> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Samandi Sami wrote: > > Hello, > > Is there any document (or work) out there describing the distribution of > logic between a feature server (or application server) and the underlying > network server asking for the services. It is true this is an implementation > issue but it is also true that this split of the roles between a SIP > application server and a SIP proxy server is similar to the IN architecture > where the SSP handles the call control and the SCP the service control. The difference between and applications server and a proxy is only in the complexity of the programs which guide their operation. Both speak SIP; both can proxy or redirect; there is no way to distinguish a proxy from an applications server from the outside. This is quite different from the SSP/SCP model, which presumes totally different interfaces and roles. I think the SIP model is a very powerful model. It means that decisions about service invocation can always be represented as routing decisions. If I want some service from provider X, all that needs to happen is to have my call routed to the server at domain X. One of the reasons the separation between call control and service control was made in the IN, was the desire for the SCP not to receive all signaling messages for the call. I will note that in SIP, this function is already provided in the call signaling itself, through the Record-Route mechanism. This means an application server can drop out of the call after routing the initial request, as can a proxy. Is > it then logical to think about an implementation like the following : > > - The network server is a call stateful proxy (holding the state of a > call between the INVITE and the BYE). This SIP proxy forward requests to the > application server. This proxy server goes stateful and proxy requests only > when needed (for instance when the end user has subscribed to predefined > services). Why? As I argue above, this distinction of an SSP/SCP role makes less sense in SIP. > - The application server will behave per call basis whether as a > redirect server (to provide routing services) or as a UAS when media > services are needed (IVR, ...). I am not sure whether this equipment should > also proxy the request ?. If that is part of the service, sure. > - The goal here is not to involve the application server for the whole > duration of the call but only when needed and this means telling the > application server what's state of the call that triggered the call of the > service. For instance, A call B, but B is busy, the Proxy server of B > receives a 486 and then sends an INVITE to the feature server asking what to > do. How to tell the application server that the user is busy (the equivalent > of the DP Terminal busy of the IN) ? Should this be done in a proprietary > way ? I would not do it this way. I would send the initial INVITE to the feature server, and when the 486 response comes, have it go from there. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 29 23:18:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07950 for ; Mon, 29 May 2000 23:18:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A93844361; Mon, 29 May 2000 23:09:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BFEDE44360 for ; Mon, 29 May 2000 23:09:32 -0400 (EDT) Received: from dynamicsoft.com (1Cust94.tnt5.freehold.nj.da.uu.net [63.36.113.94]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA00764; Mon, 29 May 2000 23:19:48 -0400 (EDT) Message-ID: <3933360B.973E87B7@dynamicsoft.com> Date: Mon, 29 May 2000 23:31:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Plong@smithmicro.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <001001bfc9aa$941216e0$6701a8c0@plong> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Plong@smithmicro.com wrote: > > Hello, all. Just starting with SIP, but I already have a few basic questions > regarding the RFC. Since this is my first query, let me know if these > questions should be posted elsewhere or I have otherwise violated some other > rule of etiquette. Many common questions are answered in the FAQ: http://www.cs.columbia.edu/~hgs/sip/faq.html > > - "...SIP...is...for...sessions with one or more participants." - How can > there be a session with only one participant? A session is defined elsewhere > as comprising one or more RTP sessions, which implies a sender and a > receiver, or two participants. Should the sentence have been written as > "...with two or more participants?" Mulicast sessions can have a single participant. Not that interesting, but possible. > > - "...the H.245 [8] gateway and user address and then use H.225.0 [9] to > establish the call." - What is meant by an "H.245 gateway address" and an > "H.245 user address?" There is no such thing. I assume that the author is > referring to the H.323 call-signaling addresses of a gateway and endpoint. > There is an H.245 control-protocol address, but if a separate H.245 channel > is even used, the address is conveyed during call establishment and not > before. You are of course correct; this should be H.323 call signaling address. > > - The word, "program,: is used throughout the RFC. Is this any functional > entity regardless of implementation and not exclusively a "software > program?" Of course. > > - "Outbound proxy" - Is there also such a thing as an inbound proxy? Not formally. That would be the proxy which receives a request where the request URI is its own domain. This is the general proxy described in the specification. Note that there can be many such proxies of each type on a call request path. > > - Regarding UA, UAC, and UAS, can this change for an entity on a per-call > basis? Can this change for an entity during a call? The role of UAC and UAS is on a request by request basis, NOT a call by call basis. This is probably confusing from the spec, as much of it was written considering the initial INVITE request, for which caller and UAC are the same. > > - "Servers are either proxy, redirect or user agent servers or > registrars." - I have also seen references to "location servers" and "SIP > servers." Is a location server the same thing as a redirect server? Is "SIP > server" just a general reference to servers in "SIPdom?" Location server is a non-SIP server, like an LDAP server or SQL database. "SIP server" is any entity that receives requests (UAS, proxy, redirect, registrar). > > - Is "server" only a role played by an entity in a single request-response > dialogue, or are some entities always servers or always clients or always > both? Same as for UAS/UAC - its on a per request basis. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 00:46:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08914 for ; Tue, 30 May 2000 00:46:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E9E144350; Tue, 30 May 2000 00:37:03 -0400 (EDT) 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 1D75744337 for ; Tue, 30 May 2000 00:37:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 30 00:45:49 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D6DAC44344; Tue, 30 May 2000 00:32:39 -0400 (EDT) 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 81B1644341 for ; Tue, 30 May 2000 00:32:39 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id XAA07402; Mon, 29 May 2000 23:32:36 -0500 From: vkg@lucent.com (Vijay K Gurbani) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id XAA07382; Mon, 29 May 2000 23:32:32 -0500 Date: Mon, 29 May 2000 23:32:32 -0500 Message-Id: <200005300432.XAA07382@ans.ih.lucent.com> Original-From: vkg@ans.ih.lucent.com (Vijay K Gurbani) To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Subject: Re: [SIP] Contact in OPTIONS Cc: lars@intertex.se, sip@lists.bell-labs.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Henning Schulzrinne wrote: > to have proxies insert Record-Route in every request. That way, the > rebooted component will still get the right information. This would seem > to be backward compatible. In this model, once a proxy adds itself to > the route, it cannot delete itself, i.e., *not* including does not imply > dropping out. Also, changing RR entries (for example, changing the maddr > part) could not be guaranteed to be respected by the other side. > > Would this work? Jonathan Rosenberg wrote: > This definitely works. Basically, what it means is that so long as a UA > has state for the call, it keeps the original route and does not try to > update. If, however, it crashes and restarts, it uses whatever it gets > in the request. This would allow it to do a partial reconstruction of > the route - "better than nothing" kind of thing, with increasing > performance as this feature is spread. > > In addition to this, we can define an explicit "remove me" record-route > entry. Something like: > > Remove-Route: ;remove=true > > Proxies would add this when they want out. A UA not understanding this > will ignore out continue to use the old route, but a new UA would know > that this means to remove it from the Route in the next request. I think > this is also backwards compatible. > > Both of these mechanisms combined (remove-route and adding record-route > for mid-call messages) has the desired result of being backwards > compatible, providing for restarts after crashes, and allowing proxies > to remove themselves during a call. Jonathan: Are you proposing a new header called "Remove-Route" or a new parameter ("remove=true") to the Record-Route header? If Remove-Route will be present in the general headers, why the "remove=true" parameter? But yes, this should work, although deployed proxies may still think that if they have included "Record-Route" in a previous request, that's all they have to do. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-418 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 May 30 00:51:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08929 for ; Tue, 30 May 2000 00:51:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE82044371; Tue, 30 May 2000 00:41:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8B2BC4436A for ; Tue, 30 May 2000 00:41:55 -0400 (EDT) Received: from dynamicsoft.com (1Cust94.tnt5.freehold.nj.da.uu.net [63.36.113.94]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00790; Tue, 30 May 2000 00:52:14 -0400 (EDT) Message-ID: <39334BB5.D713D3C7@dynamicsoft.com> Date: Tue, 30 May 2000 01:03:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay K Gurbani Cc: schulzrinne@cs.columbia.edu, lars@intertex.se, sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <200005300432.XAA07382@ans.ih.lucent.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Vijay K Gurbani wrote: > > > In addition to this, we can define an explicit "remove me" record-route > > entry. Something like: > > > > Remove-Route: ;remove=true > > > > Proxies would add this when they want out. A UA not understanding this > > will ignore out continue to use the old route, but a new UA would know > > that this means to remove it from the Route in the next request. I think > > this is also backwards compatible. > > > > Both of these mechanisms combined (remove-route and adding record-route > > for mid-call messages) has the desired result of being backwards > > compatible, providing for restarts after crashes, and allowing proxies > > to remove themselves during a call. > > Jonathan: > > Are you proposing a new header called "Remove-Route" or a new parameter > ("remove=true") to the Record-Route header? If Remove-Route will be > present in the general headers, why the "remove=true" parameter? Email edit error. I initially wrote it as part of Record-Route, and then changed my mind, but forgot to remote ;remove=true. So, its a new header (I'm not proposing it yet, though.... I'm still looking for some cases where its needed). > > But yes, this should work, although deployed proxies may still think > that if they have included "Record-Route" in a previous request, that's > all they have to do. Right, and it is. They will receive all requests for the call. Only if the client crashes and reboots, then it won't get any subsequent signaling if recovery takes place. Only new proxies would. Also, only new proxies can remove themselves. But thats all fine - new features in the new proxies, but still backwards compatible. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 00:52:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08940 for ; Tue, 30 May 2000 00:52:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 73E3F44378; Tue, 30 May 2000 00:42:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8B2BC4436A for ; Tue, 30 May 2000 00:41:55 -0400 (EDT) Received: from dynamicsoft.com (1Cust94.tnt5.freehold.nj.da.uu.net [63.36.113.94]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00790; Tue, 30 May 2000 00:52:14 -0400 (EDT) Message-ID: <39334BB5.D713D3C7@dynamicsoft.com> Date: Tue, 30 May 2000 01:03:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay K Gurbani Cc: schulzrinne@cs.columbia.edu, lars@intertex.se, sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <200005300432.XAA07382@ans.ih.lucent.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Vijay K Gurbani wrote: > > > In addition to this, we can define an explicit "remove me" record-route > > entry. Something like: > > > > Remove-Route: ;remove=true > > > > Proxies would add this when they want out. A UA not understanding this > > will ignore out continue to use the old route, but a new UA would know > > that this means to remove it from the Route in the next request. I think > > this is also backwards compatible. > > > > Both of these mechanisms combined (remove-route and adding record-route > > for mid-call messages) has the desired result of being backwards > > compatible, providing for restarts after crashes, and allowing proxies > > to remove themselves during a call. > > Jonathan: > > Are you proposing a new header called "Remove-Route" or a new parameter > ("remove=true") to the Record-Route header? If Remove-Route will be > present in the general headers, why the "remove=true" parameter? Email edit error. I initially wrote it as part of Record-Route, and then changed my mind, but forgot to remote ;remove=true. So, its a new header (I'm not proposing it yet, though.... I'm still looking for some cases where its needed). > > But yes, this should work, although deployed proxies may still think > that if they have included "Record-Route" in a previous request, that's > all they have to do. Right, and it is. They will receive all requests for the call. Only if the client crashes and reboots, then it won't get any subsequent signaling if recovery takes place. Only new proxies would. Also, only new proxies can remove themselves. But thats all fine - new features in the new proxies, but still backwards compatible. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 02:38:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21407 for ; Tue, 30 May 2000 02:38:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01E0044344; Tue, 30 May 2000 02:29:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from nw178.netaddress.usa.net (nw178.netaddress.usa.net [204.68.24.78]) by lists.bell-labs.com (Postfix) with SMTP id 8845D44337 for ; Tue, 30 May 2000 02:29:33 -0400 (EDT) Received: (qmail 7060 invoked by uid 60001); 30 May 2000 06:38:33 -0000 Message-ID: <20000530063833.7059.qmail@nw178.netaddress.usa.net> Received: from 204.68.24.78 by nw178 for [203.197.178.35] via web-mailer(34FM1.4.02C) on Tue May 30 06:38:33 GMT 2000 Date: 30 May 00 00:38:33 MDT From: Nishith Chudasama To: sip@lists.bell-labs.com X-Mailer: USANET web-mailer (34FM1.4.02C) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: [SIP] OS support Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA21407 Hi all, I am about to start working on the open source SIP code. Can anybody tell me, which all OSes are supported by the code except LINUX? I had an overview of the code and could find some lines with "#ifdef VXWORKS". Has this code been ported to VXWORKS? Thanks & 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 Tue May 30 03:35:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21796 for ; Tue, 30 May 2000 03:35:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E398044338; Tue, 30 May 2000 03:26:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from paris.mds.local (rdu162-225-005.nc.rr.com [24.162.225.5]) by lists.bell-labs.com (Postfix) with ESMTP id 6A29B44337 for ; Tue, 30 May 2000 03:26:38 -0400 (EDT) Received: from berlin (berlin.mds.local [192.168.1.4]) by paris.mds.local (8.8.7/8.8.7) with SMTP id DAA32708; Tue, 30 May 2000 03:35:24 -0400 Message-ID: <05e701bfca09$a27b4fd0$0401a8c0@mds.local> From: "Paul E. Jones" To: "Nishith Chudasama" , References: <20000530063833.7059.qmail@nw178.netaddress.usa.net> Subject: Re: [SIP] OS support Date: Tue, 30 May 2000 03:35:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Nishith, Which open source SIP code? I am aware of a few projects. Paul ----- Original Message ----- From: "Nishith Chudasama" To: Sent: Tuesday, May 30, 2000 2:38 AM Subject: [SIP] OS support > Hi all, > > I am about to start working on the open source SIP code. > > Can anybody tell me, which all OSes are supported by the code except LINUX? > > I had an overview of the code and could find some lines with "#ifdef > VXWORKS". > Has this code been ported to VXWORKS? > > Thanks & 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 04:44:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22125 for ; Tue, 30 May 2000 04:44:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 649D04434E; Tue, 30 May 2000 04:35:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 15B8944337 for ; Tue, 30 May 2000 04:35:24 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA29845; Tue, 30 May 2000 09:41:57 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "Henning Schulzrinne" Cc: "Adam B. Roach" , Subject: RE: [SIP] Contact in OPTIONS Date: Tue, 30 May 2000 09:41:57 +0100 Message-ID: <003001bfca12$ea210d80$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: <3930B309.2DD20E61@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gentlemen, > > > Presumably, this function (TCP/UDP translation) would be provided > > > only if the clients couldn't talk to each other directly (e.g. > > > one is TCP only, and the other is UDP only). In this case, the > > > proxy must remain in the path to continue to provide TCP/UDP > > > translation for the duration of the call leg. > > > > Since then, some additional discussion seems to indicate that things > > get a lot easier if we require UAs to speak UDP as the lingua franca. > > Otherwise, we can't satisfy the goal of simply plugging in a bunch of > > SIP phones and setting up calls, without a proxy. So are we saying that adding a Record-Route header is not necessary just because a proxy is acting as a TCP/UDP bridge? > To be specific, the proposal is that UDP support in UA transition from > SHOULD to MUST, so that: > > 1. UAs SHOULD support TCP, MUST support UDP > 2. proxies MUST support TCP and UDP > > The transport parameter in the Contact and Record-Route headers then > becomes the preferential choice; if not supported, you can always fall > back to UDP. Hmmm... isn't the implication of this that servers should ensure that for every TCP port listened on (apologies for the socket-oriented terminology), they have also bound a UDP socket with the same port number? Furthermore, these ports should have the same semantics? (I can imagine a proxy that exhibits different behaviour on different ports.) Is this ever going to be a problem? (I suspect not, but it prob. needs to be stated, if not already.) - 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 May 30 05:14:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22275 for ; Tue, 30 May 2000 05:14:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 29A4344338; Tue, 30 May 2000 05:05:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 01BB744337 for ; Tue, 30 May 2000 05:05:25 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA08768; Tue, 30 May 2000 10:12:02 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "sip" Subject: RE: [SIP] wg last call on reliable provisional responses Date: Tue, 30 May 2000 10:12:02 +0100 Message-ID: <003101bfca17$1de7eae0$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: <3930D614.972F8D1A@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, (SIP List: Apologies for the use of "Gentlemen" in my last post; very poor indeed.) > I've just submitted an updated version of the I-D on "Reliability of > Provisional Responses in SIP". Until it appears in the archives, you > can find a copy at: [...] Well it's certainly easier for a proxy than the original draft (00). Which makes me happy. &:) One thing I'm a little confused about: Section 5.2 (UAS Behavior) contains the following text: "Note that a UAS can send reliable provisional responses for any request, including a PRACK request. It is anticipated that reliable provisional responses will be most useful for INVITE requests." Is allowing a PRACK to be responded to with reliable provisional responses potentially a big old nightmare? Or am I just being a little bit dull, really? Also, shouldn't it be stated that reliable provisional responses can't be used with ACK? 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 Tue May 30 05:27:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22297 for ; Tue, 30 May 2000 05:27:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D84E4436B; Tue, 30 May 2000 05:18:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A672244343 for ; Tue, 30 May 2000 05:18:08 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA15781; Tue, 30 May 2000 10:25:17 +0100 (BST) Message-ID: <393388FD.E273F666@ubiquity.net> Date: Tue, 30 May 2000 10:25:17 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: <679076A067F2D211A8F70090274481B815159B@LNN201E> <39333355.5BB5B119@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Samandi Sami wrote: > > > > Hello, > > > > Is there any document (or work) out there describing the distribution of > > logic between a feature server (or application server) and the underlying > > network server asking for the services. The Softswitch consortium's Application Working Group are interested in this area you might want to also look into their work ... http://www.softswitch.org/Working_Groups/application.html > It is true this is an implementation > > issue but it is also true that this split of the roles between a SIP > > application server and a SIP proxy server is similar to the IN architecture > > where the SSP handles the call control and the SCP the service control. > > The difference between and applications server and a proxy is only in > the complexity of the programs which guide their operation. > > Both speak SIP; both can proxy or redirect; there is no way to > distinguish a proxy from an applications server from the outside. This > is quite different from the SSP/SCP model, which presumes totally > different interfaces and roles. I am not part of the Softswitch Application Working Group, and certainly do not speak for them, but to me this doesn't appear to totally fit with what I understand to be their position. I know there are people on this list close to this work, perhaps they would care to comment. The Softswitch Application Group are seeking to define the interfaces between an Application Server and a Softswitch. As I understand it a SIP Proxy Server can be one example of a Softswitch. They have described the Softswitch as providing basic call control and signalling, managing resources, and generating call detail records. Whereas application servers host the service logic for a variety of enhanced services and media servers provide bearer oriented functions, such as IVR, conferencing, and fax. They suggest SIP is used as the interface between an Application Server and a Softswitch, while the Real Time Protocol (RTP) is used as the interface between a media server and media gateway. Please note I am not seeking to promote the Softswitch view over the one described by Jonathan, which I personally empathise with, just some discussion of a very interesting area. Regards, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net > I think the SIP model is a very powerful > model. It means that decisions about service invocation can always be > represented as routing decisions. If I want some service from provider > X, all that needs to happen is to have my call routed to the server at > domain X. > > One of the reasons the separation between call control and service > control was made in the IN, was the desire for the SCP not to receive > all signaling messages for the call. I will note that in SIP, this > function is already provided in the call signaling itself, through the > Record-Route mechanism. This means an application server can drop out of > the call after routing the initial request, as can a proxy. > > Is > > it then logical to think about an implementation like the following : > > > > - The network server is a call stateful proxy (holding the state of a > > call between the INVITE and the BYE). This SIP proxy forward requests to the > > application server. This proxy server goes stateful and proxy requests only > > when needed (for instance when the end user has subscribed to predefined > > services). > > Why? As I argue above, this distinction of an SSP/SCP role makes less > sense in SIP. > > > - The application server will behave per call basis whether as a > > redirect server (to provide routing services) or as a UAS when media > > services are needed (IVR, ...). I am not sure whether this equipment should > > also proxy the request ?. > > If that is part of the service, sure. > > > - The goal here is not to involve the application server for the whole > > duration of the call but only when needed and this means telling the > > application server what's state of the call that triggered the call of the > > service. For instance, A call B, but B is busy, the Proxy server of B > > receives a 486 and then sends an INVITE to the feature server asking what to > > do. How to tell the application server that the user is busy (the equivalent > > of the DP Terminal busy of the IN) ? Should this be done in a proprietary > > way ? > > I would not do it this way. I would send the initial INVITE to the > feature server, and when the 486 response comes, have it go from there. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 07:37:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25000 for ; Tue, 30 May 2000 07:37:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 351C34433C; Tue, 30 May 2000 07:28:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 1C65B44337 for ; Tue, 30 May 2000 07:28:33 -0400 (EDT) Date: Tue, 30 May 2000 13:39:32 +0200 (CEST) From: Lars Berggren To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Comment on section 6.34.3 in rfc2543bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I quote: "We define the calling URI as the URI found in the Contact header of the request from the calling UA, if present, or the From header, if there is no Contact header. The called UA copies the Record-Route entries, maintaining their ordering, to the Route header field. However, all components except the maddr parameter are replaced by the calling URI." As I interpret this, a proxy can not specify which port or the transport protocol it wants to be used in subsequent requests from the called UA since the only parameter of the url of the proxy that is reflected in the Route-list is maddr. Is this correct? What about rr-extension, is it supposed to be copied into the route field as a route-extension or is that supposed to be defined by the extension? I think it could be useful for a proxy to signal that it wants to have the rr-extension copied into subsequent requests in some way. For example, a call stateful proxy could store call state in a rr-extension parameter. Thanks /Lars Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 08:20:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26514 for ; Tue, 30 May 2000 08:20:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6EDA944348; Tue, 30 May 2000 08:11:01 -0400 (EDT) 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 E957044337 for ; Tue, 30 May 2000 08:10:58 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 30 08:18:33 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3BD6A44345; Tue, 30 May 2000 08:05:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 13AD044341 for ; Tue, 30 May 2000 08:05:24 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3102252C4; Tue, 30 May 2000 08:05:30 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5258D52B6 for ; Tue, 30 May 2000 08:05:27 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 30 08:04:39 EDT 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Tue May 30 08:04:38 EDT 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4UC4ZJ11364 for ; Tue, 30 May 2000 14:04:35 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA28040 for ; Tue, 30 May 2000 15:04:32 +0300 (EET DST) Message-ID: <3933AE36.8A67FD2D@lmf.ericsson.se> Date: Tue, 30 May 2000 15:04:06 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Retransmissions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, In section 10.5.1 of the bis document it is said that when UDP is used a final response is retransmitted until: 1) ACK arrives 2) BYE arrives 3) CANCEL arrives (status code > 299) 4) 7 retransmissions In section 4.2.5 it is said that CANCEL has to be answered with 487. So, if a server receives an INVITE and it responses with 400 for instance. If a CANCEL is received, it will stop sending the 400 and it will send the 487. It will retransmit the 487 until the ACK for the INVITE arrives. Does the retransmission counter get re-started (the server might have retransmitted already some times the 400 response)? Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 08:42:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27210 for ; Tue, 30 May 2000 08:42:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA6A744346; Tue, 30 May 2000 08:33:25 -0400 (EDT) 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 BDB1C44338 for ; Tue, 30 May 2000 08:33:22 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id SAA04624; Tue, 30 May 2000 18:44:26 -0500 Message-Id: <200005302344.SAA04624@kevlar.softarmor.com> Date: Tue, 30 May 2000 07:44:37 -0500 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Plong@smithmicro.com, sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <001001bfc9aa$941216e0$6701a8c0@plong> <3933360B.973E87B7@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Plong@smithmicro.com wrote: > > > > Hello, all. Just starting with SIP, but I already have a few basic questions > > regarding the RFC. Since this is my first query, let me know if these > > questions should be posted elsewhere or I have otherwise violated some other > > rule of etiquette. > > Many common questions are answered in the FAQ: > http://www.cs.columbia.edu/~hgs/sip/faq.html > > > > > - "...SIP...is...for...sessions with one or more participants." - How can > > there be a session with only one participant? A session is defined elsewhere > > as comprising one or more RTP sessions, which implies a sender and a > > receiver, or two participants. Should the sentence have been written as > > "...with two or more participants?" > > Mulicast sessions can have a single participant. Not that interesting, > but possible. > Note that a "session" does not have to be RTP. It might have an RTP component, might have several RTP components, or none at all. I might also have an associated "Quake" game, SIGTRAN connection, or anything else that can be described from a third-person perspective. > > - "Servers are either proxy, redirect or user agent servers or > > registrars." - I have also seen references to "location servers" and "SIP > > servers." Is a location server the same thing as a redirect server? Is "SIP > > server" just a general reference to servers in "SIPdom?" > > Location server is a non-SIP server, like an LDAP server or SQL > database. "SIP server" is any entity that receives requests (UAS, proxy, > redirect, registrar). This may be a slightly misleading statements. Many implemented Location Servers are in fact SIP Servers hat have access to additional routing data such as LDAP. -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 08:56:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27581 for ; Tue, 30 May 2000 08:56:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B372A44366; Tue, 30 May 2000 08:47:01 -0400 (EDT) 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 2B86844337 for ; Tue, 30 May 2000 08:46:59 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 30 08:54:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7938A44344; Tue, 30 May 2000 08:41:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 461AF44341 for ; Tue, 30 May 2000 08:41:11 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9ABE052C4; Tue, 30 May 2000 08:41:29 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B144B52AB for ; Tue, 30 May 2000 08:41:26 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 30 08:39:14 EDT 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Tue May 30 08:39:11 EDT 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA09814; Tue, 30 May 2000 18:49:27 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568EF.0045CC6F ; Tue, 30 May 2000 18:12:23 +0530 X-Lotus-FromDomain: HSSBLR From: kbinu@hss.hns.com To: Gonzalo Camarillo Cc: sip Message-ID: <652568EF.0045CA83.00@sampark.hss.hns.com> Date: Tue, 30 May 2000 18:12:18 +0530 Subject: Re: [SIP] Retransmissions 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Gonzalo, Answers inline. Gonzalo Camarillo on 05/30/2000 05:34:06 PM To: sip cc: (bcc: K Binu/HSSBLR) Subject: [SIP] Retransmissions >Hi, > >In section 10.5.1 of the bis document it is said that when UDP is used a >final response is retransmitted until: > >1) ACK arrives >2) BYE arrives >3) CANCEL arrives (status code > 299) >4) 7 retransmissions > >In section 4.2.5 it is said that CANCEL has to be answered with 487. > The section does not say that CANCEL is to be answered with a 487. The CANCEL has to be answered with a 200 OK. The 487 response is to be sent if a retransmission of the cancelled INVITE request comes by. >So, if a server receives an INVITE and it responses with 400 for >instance. If a CANCEL is received, it will stop sending the 400 and it >will send the 487. It will retransmit the 487 until the ACK for the >INVITE arrives. Does the retransmission counter get re-started (the >server might have retransmitted already some times the 400 response)? So the correct behaviour here would be to stop the 400 response retransmissions for the INVITE and answer the CANCEL with a 200 OK. The server would send a 487 if the cancelled INVITE happens to come by and not otherwise. > >Thanks, > >Gonzalo >-- >Gonzalo Camarillo Phone : +358 9 299 33 71 >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >Telecom R&D Fax : +358 9 299 30 52 >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >Finland > > >______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip 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 May 30 09:00:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27675 for ; Tue, 30 May 2000 09:00:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 715C144371; Tue, 30 May 2000 08:51:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 955384436F for ; Tue, 30 May 2000 08:51:21 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA29735; Tue, 30 May 2000 13:58:11 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sip Mail List Date: Tue, 30 May 2000 13:34:06 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00053013571100.24017@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] Receiver-tagged Via Headers and hidden parameter Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit hi, I'm querying the use of the hidden parameter and received parameter in the same via. It is the purpose of the hidden parameter to hide the previous hop from subsequent hopes and this is done by encrypting the 'sent-by' part of the Via header. However, it is possible that the Proxy has added a received parameter to the encrypted via in order to reply to the correct machine. This received parameter provides open knowledge of the previous hop's address and compromises the security. Now there are two possibilities here (as far as i can see): 1) The received parameter should not be added to the hidden via but cached by the proxy in a lookup table whilst it waits for the response. (or the received parameter can be encrypted as well). 2) For a received parameter to be inserted, then the message has probably come through a NAT or firewall. this is sufficent enough for security matters and aslong as the original host is encrypted within the via i.e. the sent-by remains encrypted, all is OK. any thoughts? -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@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 May 30 09:06:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27925 for ; Tue, 30 May 2000 09:06:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6ABA244388; Tue, 30 May 2000 08:56:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from helios.iihe.ac.be (sun1.iihe.ac.be [193.190.247.71]) by lists.bell-labs.com (Postfix) with ESMTP id BB3DC4437D for ; Tue, 30 May 2000 08:56:29 -0400 (EDT) Received: from helios.iihe.ac.be (spc27.iihe.ac.be [193.190.247.27]) by helios.iihe.ac.be (8.9.3/8.9.3) with ESMTP id PAA06522; Tue, 30 May 2000 15:05:48 +0100 (WET DST) Message-ID: <3933BCB1.8588EB31@helios.iihe.ac.be> Date: Tue, 30 May 2000 15:05:53 +0200 From: charles Agboh X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis , "sip@lists.bell-labs.com" Cc: Jonathan Rosenberg Subject: Re: [SIP] Basic questions References: <001001bfc9aa$941216e0$6701a8c0@plong> <3933360B.973E87B7@dynamicsoft.com> <200005302344.SAA04624@kevlar.softarmor.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Can somebody please answer the following question? " How can you have a "session" of any kind with only one participant? charles Dean Willis wrote: > Jonathan Rosenberg wrote: > > > > Plong@smithmicro.com wrote: > > > > > > Hello, all. Just starting with SIP, but I already have a few basic questions > > > regarding the RFC. Since this is my first query, let me know if these > > > questions should be posted elsewhere or I have otherwise violated some other > > > rule of etiquette. > > > > Many common questions are answered in the FAQ: > > http://www.cs.columbia.edu/~hgs/sip/faq.html > > > > > > > > - "...SIP...is...for...sessions with one or more participants." - How can > > > there be a session with only one participant? A session is defined elsewhere > > > as comprising one or more RTP sessions, which implies a sender and a > > > receiver, or two participants. Should the sentence have been written as > > > "...with two or more participants?" > > > > Mulicast sessions can have a single participant. Not that interesting, > > but possible. > > > > Note that a "session" does not have to be RTP. It might have an RTP > component, might have several RTP components, or none at all. I might > also have an associated "Quake" game, SIGTRAN connection, or anything > else that can be described from a third-person perspective. > > > > - "Servers are either proxy, redirect or user agent servers or > > > registrars." - I have also seen references to "location servers" and "SIP > > > servers." Is a location server the same thing as a redirect server? Is "SIP > > > server" just a general reference to servers in "SIPdom?" > > > > Location server is a non-SIP server, like an LDAP server or SQL > > database. "SIP server" is any entity that receives requests (UAS, proxy, > > redirect, registrar). > > This may be a slightly misleading statements. Many implemented Location > Servers are in fact SIP Servers hat have access to additional routing > data such as LDAP. > > -- > Dean > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Charles Agboh Universite Libre de Bruxelles Service Telematique et Communication Bd du Triomphe, CP 230 B-1050 Brussels Belgium Tel. +32 2 6505717 Fax. +32 2 6505088, +32 2 6293816 RFC-822 : agboh@helios.iihe.ac.be ---------------------------------- "Perilous to us all are the devices of an art deeper than we possess ourselves." --J.R.R Tolkien, The Two Towers _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 09:26:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28238 for ; Tue, 30 May 2000 09:26:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DC024435C; Tue, 30 May 2000 09:17:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tti-intranet.tti.net (unknown [216.86.19.250]) by lists.bell-labs.com (Postfix) with ESMTP id 2FE0644337 for ; Tue, 30 May 2000 09:17:11 -0400 (EDT) Received: from ttimail.com ([10.10.100.5]) by tti-intranet.tti.net with Microsoft SMTPSVC(5.0.2172.1); Tue, 30 May 2000 08:26:04 -0500 Received: by mailhost.tti.net with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 08:25:29 -0500 Message-ID: From: Kevin Summers To: "'charles Agboh'" , Dean Willis , sip@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: RE: [SIP] Basic questions Date: Tue, 30 May 2000 08:25:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 May 2000 13:26:04.0252 (UTC) FILETIME=[9ABAF1C0:01BFCA3A] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I know my head is shaped like a bell, but a self-test on a given interface is rather common. -----Original Message----- From: charles Agboh [mailto:agboh@helios.iihe.ac.be] Sent: Tuesday, May 30, 2000 8:06 AM To: Dean Willis; sip@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: Re: [SIP] Basic questions Can somebody please answer the following question? " How can you have a "session" of any kind with only one participant? charles Dean Willis wrote: > Jonathan Rosenberg wrote: > > > > Plong@smithmicro.com wrote: > > > > > > Hello, all. Just starting with SIP, but I already have a few basic questions > > > regarding the RFC. Since this is my first query, let me know if these > > > questions should be posted elsewhere or I have otherwise violated some other > > > rule of etiquette. > > > > Many common questions are answered in the FAQ: > > http://www.cs.columbia.edu/~hgs/sip/faq.html > > > > > > > > - "...SIP...is...for...sessions with one or more participants." - How can > > > there be a session with only one participant? A session is defined elsewhere > > > as comprising one or more RTP sessions, which implies a sender and a > > > receiver, or two participants. Should the sentence have been written as > > > "...with two or more participants?" > > > > Mulicast sessions can have a single participant. Not that interesting, > > but possible. > > > > Note that a "session" does not have to be RTP. It might have an RTP > component, might have several RTP components, or none at all. I might > also have an associated "Quake" game, SIGTRAN connection, or anything > else that can be described from a third-person perspective. > > > > - "Servers are either proxy, redirect or user agent servers or > > > registrars." - I have also seen references to "location servers" and "SIP > > > servers." Is a location server the same thing as a redirect server? Is "SIP > > > server" just a general reference to servers in "SIPdom?" > > > > Location server is a non-SIP server, like an LDAP server or SQL > > database. "SIP server" is any entity that receives requests (UAS, proxy, > > redirect, registrar). > > This may be a slightly misleading statements. Many implemented Location > Servers are in fact SIP Servers hat have access to additional routing > data such as LDAP. > > -- > Dean > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Charles Agboh Universite Libre de Bruxelles Service Telematique et Communication Bd du Triomphe, CP 230 B-1050 Brussels Belgium Tel. +32 2 6505717 Fax. +32 2 6505088, +32 2 6293816 RFC-822 : agboh@helios.iihe.ac.be ---------------------------------- "Perilous to us all are the devices of an art deeper than we possess ourselves." --J.R.R Tolkien, The Two Towers _______________________________________________ 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 May 30 09:33:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28437 for ; Tue, 30 May 2000 09:33:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 141914436F; Tue, 30 May 2000 09:23:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id DFB814436C for ; Tue, 30 May 2000 09:23:47 -0400 (EDT) Date: Tue, 30 May 2000 15:34:40 +0200 (CEST) From: Lars Berggren To: charles Agboh Cc: Dean Willis , "sip@lists.bell-labs.com" , Jonathan Rosenberg Subject: Re: [SIP] Basic questions In-Reply-To: <3933BCB1.8588EB31@helios.iihe.ac.be> Message-ID: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On Tue, 30 May 2000, charles Agboh wrote: > > Can somebody please answer the following question? " > > How can you have a "session" of any kind with only one participant? > > charles Jonathan gave a good example: multicast sessions. Imagine you are the only one which sends and/or receives "session data" to a multicast ip-address. Then you might end up "talking to yourself", but still, it *is* a session with only one participant. /Lars Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 09:36:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28550 for ; Tue, 30 May 2000 09:36:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C213044398; Tue, 30 May 2000 09:25:04 -0400 (EDT) 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 84D634436C for ; Tue, 30 May 2000 09:25:00 -0400 (EDT) Received: from scott ([216.181.56.35]) by broadsoft.com (8.8.8) id JAA86253; Tue, 30 May 2000 09:34:00 -0400 (EDT) From: "Scott Hoffpauir" To: Subject: RE: [SIP] SIP Application Server Date: Tue, 30 May 2000 09:34:24 -0400 Message-ID: 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <393388FD.E273F666@ubiquity.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The softswitch consortium applications working group is working on an architecture supporting enhanced services in the softswitch network architecture. An application server is introduced into the architecture to host enhanced service logic and management functions. While a softswitch provides basic call control and signaling, manages resources, and generates call detail records, application servers are intended to host a variety of enhanced services. Examples of enhanced services include calling card, 800 number translation, Centrex, voice mail, and find-me services. SIP is used as the interface between an application server and a softswitch. It allows a softswitch to direct calls to an application server for enhanced services processing and also allows an application server to redirect or transfer calls back through a softswitch. An applications server can be a proxy, redirect server or user agent. It may be stateful or stateless. It really depends on the applications being provided. I've seen applications servers which are simple redirect servers providing routing functions and more complex ones acting as back-to-back user agents, providing unified messaging. Using SIP allows a softswitch (or other end user device) to pass control to an application server, without having to worry about its architecture or functions. Scott Hoffpauir BroadSoft, Inc. 200 Perry Parkway, Suite 1 Gaithersburg, MD 20878 301-977-4295 -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Neil Deason Sent: Tuesday, May 30, 2000 5:25 AM To: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server Jonathan Rosenberg wrote: > Samandi Sami wrote: > > > > Hello, > > > > Is there any document (or work) out there describing the distribution of > > logic between a feature server (or application server) and the underlying > > network server asking for the services. The Softswitch consortium's Application Working Group are interested in this area you might want to also look into their work ... http://www.softswitch.org/Working_Groups/application.html > It is true this is an implementation > > issue but it is also true that this split of the roles between a SIP > > application server and a SIP proxy server is similar to the IN architecture > > where the SSP handles the call control and the SCP the service control. > > The difference between and applications server and a proxy is only in > the complexity of the programs which guide their operation. > > Both speak SIP; both can proxy or redirect; there is no way to > distinguish a proxy from an applications server from the outside. This > is quite different from the SSP/SCP model, which presumes totally > different interfaces and roles. I am not part of the Softswitch Application Working Group, and certainly do not speak for them, but to me this doesn't appear to totally fit with what I understand to be their position. I know there are people on this list close to this work, perhaps they would care to comment. The Softswitch Application Group are seeking to define the interfaces between an Application Server and a Softswitch. As I understand it a SIP Proxy Server can be one example of a Softswitch. They have described the Softswitch as providing basic call control and signalling, managing resources, and generating call detail records. Whereas application servers host the service logic for a variety of enhanced services and media servers provide bearer oriented functions, such as IVR, conferencing, and fax. They suggest SIP is used as the interface between an Application Server and a Softswitch, while the Real Time Protocol (RTP) is used as the interface between a media server and media gateway. Please note I am not seeking to promote the Softswitch view over the one described by Jonathan, which I personally empathise with, just some discussion of a very interesting area. Regards, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net > I think the SIP model is a very powerful > model. It means that decisions about service invocation can always be > represented as routing decisions. If I want some service from provider > X, all that needs to happen is to have my call routed to the server at > domain X. > > One of the reasons the separation between call control and service > control was made in the IN, was the desire for the SCP not to receive > all signaling messages for the call. I will note that in SIP, this > function is already provided in the call signaling itself, through the > Record-Route mechanism. This means an application server can drop out of > the call after routing the initial request, as can a proxy. > > Is > > it then logical to think about an implementation like the following : > > > > - The network server is a call stateful proxy (holding the state of a > > call between the INVITE and the BYE). This SIP proxy forward requests to the > > application server. This proxy server goes stateful and proxy requests only > > when needed (for instance when the end user has subscribed to predefined > > services). > > Why? As I argue above, this distinction of an SSP/SCP role makes less > sense in SIP. > > > - The application server will behave per call basis whether as a > > redirect server (to provide routing services) or as a UAS when media > > services are needed (IVR, ...). I am not sure whether this equipment should > > also proxy the request ?. > > If that is part of the service, sure. > > > - The goal here is not to involve the application server for the whole > > duration of the call but only when needed and this means telling the > > application server what's state of the call that triggered the call of the > > service. For instance, A call B, but B is busy, the Proxy server of B > > receives a 486 and then sends an INVITE to the feature server asking what to > > do. How to tell the application server that the user is busy (the equivalent > > of the DP Terminal busy of the IN) ? Should this be done in a proprietary > > way ? > > I would not do it this way. I would send the initial INVITE to the > feature server, and when the 486 response comes, have it go from there. _______________________________________________ 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 May 30 09:39:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28591 for ; Tue, 30 May 2000 09:39:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB949443A7; Tue, 30 May 2000 09:28:57 -0400 (EDT) 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 23018443A3 for ; Tue, 30 May 2000 09:28:55 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FVD00C01KJ9D0@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 30 May 2000 13:37:57 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FVD005FZKJ95O@firewall.mcit.com>; Tue, 30 May 2000 13:37:57 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FVD00F01KHMU8@pmismtp03.wcomnet.com>; Tue, 30 May 2000 13:36:58 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FVD00F01KHDSZ@pmismtp03.wcomnet.com>; Tue, 30 May 2000 13:36:58 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FVD00E77KH743@pmismtp03.wcomnet.com>; Tue, 30 May 2000 13:36:43 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Tue, 30 May 2000 13:37:41 +0000 Content-return: allowed Date: Tue, 30 May 2000 13:37:39 +0000 From: "Sinnreich, Henry" Subject: RE: [SIP] OS support To: "'Nishith Chudasama'" , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D85B2757@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com See an extensive list at http://www.cs.columbia.edu/sip/implementations.html and other several sources, such as http://www.vovida.com/content.cfm?pagename=products Henry Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA >-----Original Message----- >From: Nishith Chudasama [mailto:nishith76@usa.net] >Sent: Tuesday, May 30, 2000 1:39 AM >To: sip@lists.bell-labs.com >Subject: [SIP] OS support > > >Hi all, > >I am about to start working on the open source SIP code. > >Can anybody tell me, which all OSes are supported by the code >except LINUX? > >I had an overview of the code and could find some lines with "#ifdef >VXWORKS". >Has this code been ported to VXWORKS? > >Thanks & 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 09:41:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28651 for ; Tue, 30 May 2000 09:41:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 48574443AD; Tue, 30 May 2000 09:30:59 -0400 (EDT) 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 5EA1044393 for ; Tue, 30 May 2000 09:30:56 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id TAA04769; Tue, 30 May 2000 19:42:00 -0500 Message-ID: <3933C533.205FD481@dynamicsoft.com> Date: Tue, 30 May 2000 08:42:11 -0500 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: charles Agboh Cc: "sip@lists.bell-labs.com" , Jonathan Rosenberg Subject: Re: [SIP] Basic questions References: <001001bfc9aa$941216e0$6701a8c0@plong> <3933360B.973E87B7@dynamicsoft.com> <200005302344.SAA04624@kevlar.softarmor.com> <3933BCB1.8588EB31@helios.iihe.ac.be> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I regularly multicast myself to no particular audience. Occasionally I join the multicast to see if I'm still there and tell people I'm checking up on myself. Lacking WAN mulicast routing, my traffic doesn't go all that far -- but it's still a session, even when nobody is joined. Hence "one or more" participants rather than "zero or more". -- Dean charles Agboh wrote: > > Can somebody please answer the following question? " > > How can you have a "session" of any kind with only one participant? > > charles > Dean Willis wrote: > > > Jonathan Rosenberg wrote: > > > > > > Plong@smithmicro.com wrote: > > > > > > > > Hello, all. Just starting with SIP, but I already have a few basic questions > > > > regarding the RFC. Since this is my first query, let me know if these > > > > questions should be posted elsewhere or I have otherwise violated some other > > > > rule of etiquette. > > > > > > Many common questions are answered in the FAQ: > > > http://www.cs.columbia.edu/~hgs/sip/faq.html > > > > > > > > > > > - "...SIP...is...for...sessions with one or more participants." - How can > > > > there be a session with only one participant? A session is defined elsewhere > > > > as comprising one or more RTP sessions, which implies a sender and a > > > > receiver, or two participants. Should the sentence have been written as > > > > "...with two or more participants?" > > > > > > Mulicast sessions can have a single participant. Not that interesting, > > > but possible. > > > > > > > Note that a "session" does not have to be RTP. It might have an RTP > > component, might have several RTP components, or none at all. I might > > also have an associated "Quake" game, SIGTRAN connection, or anything > > else that can be described from a third-person perspective. > > > > > > - "Servers are either proxy, redirect or user agent servers or > > > > registrars." - I have also seen references to "location servers" and "SIP > > > > servers." Is a location server the same thing as a redirect server? Is "SIP > > > > server" just a general reference to servers in "SIPdom?" > > > > > > Location server is a non-SIP server, like an LDAP server or SQL > > > database. "SIP server" is any entity that receives requests (UAS, proxy, > > > redirect, registrar). > > > > This may be a slightly misleading statements. Many implemented Location > > Servers are in fact SIP Servers hat have access to additional routing > > data such as LDAP. > > > > -- > > Dean > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > > Charles Agboh > > Universite Libre de Bruxelles > Service Telematique et Communication > Bd du Triomphe, CP 230 > B-1050 Brussels > Belgium > > Tel. +32 2 6505717 > Fax. +32 2 6505088, +32 2 6293816 > RFC-822 : agboh@helios.iihe.ac.be > > ---------------------------------- > "Perilous to us all are the devices of an art deeper than we possess ourselves." > --J.R.R Tolkien, The Two Towers _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 10:30:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29733 for ; Tue, 30 May 2000 10:30:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DC82044340; Tue, 30 May 2000 10:20:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from avmail.smithmicro.com (avmail.smithmicro.com [209.218.67.201]) by lists.bell-labs.com (Postfix) with ESMTP id 30EF044337 for ; Tue, 30 May 2000 10:20:50 -0400 (EDT) Received: by AVMAIL with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 07:29:39 -0700 Received: from plong (adsl-32.statton.austx.uSOLnet.net [63.80.75.161]) by avmail.smithmicro.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LQ4RTK96; Tue, 30 May 2000 07:29:30 -0700 From: Plong@smithmicro.com To: dwillis@dynamicsoft.com, jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Basic questions Date: Tue, 30 May 2000 09:16:08 -0500 Message-ID: <000b01bfca41$99f4b760$6701a8c0@plong> 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: <200005302344.SAA04624@kevlar.softarmor.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dean, So is this statement incorrect? Section 1.3: "A session as defined for SDP can comprise one or more RTP sessions." Paul Long (an admitted hair splitter) Smith Micro Software, Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 12:41:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04113 for ; Tue, 30 May 2000 12:41:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 893C344346; Tue, 30 May 2000 12:32:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id BDA2D44337 for ; Tue, 30 May 2000 12:32:24 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA08903; Tue, 30 May 2000 17:39:15 +0100 (BST) Message-ID: <3933EEB2.893C06AB@ubiquity.net> Date: Tue, 30 May 2000 17:39:14 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Scott Hoffpauir Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Thanks for providing the authoritive voice from the working group Scott. Scott Hoffpauir wrote: > The softswitch consortium applications working group is working on an > architecture supporting enhanced services in the softswitch network > architecture. An application server is introduced into the architecture to > host enhanced service logic and management functions. While a softswitch > provides basic call control and signaling, manages resources, and generates > call detail records, application servers are intended to host a variety of > enhanced services. Examples of enhanced services include calling card, 800 > number translation, Centrex, voice mail, and find-me services. SIP is used > as the interface between an application server and a softswitch. It allows a > softswitch to direct calls to an application server for enhanced services > processing and also allows an application server to redirect or transfer > calls back through a softswitch. > > An applications server can be a proxy, redirect server or user agent. It may > be stateful or stateless. It really depends on the applications being > provided. I've seen applications servers which are simple redirect servers > providing routing functions and more complex ones acting as back-to-back > user agents, providing unified messaging. Using SIP allows a softswitch (or > other end user device) to pass control to an application server, without > having to worry about its architecture or functions. My apologies if I am confusing the terms here but am I wrong in thinking that a SIP Proxy Server qualifies as a Softswitch? I have seen them described as such within the Softswitch Consortium. If a SIP Proxy is a Softswitch, isn't this approach in danger of reproducing the SSP/SCP model? Why would a Proxy Server need to pass an INVITE on to an Application Server for the AS to then proxy/redirect it? Couldn't SIP-CGI and CPL provide ways for a Proxy to access any service logic required to decide whether to proxy/redirect it directly. A Proxy Server augmented with service logic seems to be both a Softswitch and an Application Server, which would make defining an interface based on SIP between the two interesting. Regards, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > Jonathan Rosenberg wrote: > > > Samandi Sami wrote: > > > > > > Hello, > > > > > > Is there any document (or work) out there describing the distribution of > > > logic between a feature server (or application server) and the > underlying > > > network server asking for the services. > > The Softswitch consortium's Application Working Group are interested in this > area > you might want to also look into their work ... > http://www.softswitch.org/Working_Groups/application.html > > > It is true this is an implementation > > > issue but it is also true that this split of the roles between a SIP > > > application server and a SIP proxy server is similar to the IN > architecture > > > where the SSP handles the call control and the SCP the service control. > > > > The difference between and applications server and a proxy is only in > > the complexity of the programs which guide their operation. > > > > Both speak SIP; both can proxy or redirect; there is no way to > > distinguish a proxy from an applications server from the outside. This > > is quite different from the SSP/SCP model, which presumes totally > > different interfaces and roles. > > I am not part of the Softswitch Application Working Group, and certainly do > not > speak for them, but to me this doesn't appear to totally fit with what I > understand to be their position. I know there are people on this list close > to > this work, perhaps they would care to comment. > > The Softswitch Application Group are seeking to define the interfaces > between an > Application Server and a Softswitch. As I understand it a SIP Proxy Server > can be > one example of a Softswitch. They have described the Softswitch as providing > basic > call control and signalling, managing resources, and generating call detail > records. Whereas application servers host the service logic for a variety of > enhanced services and media servers provide bearer oriented functions, such > as > IVR, conferencing, and fax. They suggest SIP is used as the interface > between an > Application Server and a Softswitch, while the Real Time Protocol (RTP) is > used as > the interface between a media server and media gateway. > > Please note I am not seeking to promote the Softswitch view over the one > described > by Jonathan, which I personally empathise with, just some discussion of a > very > interesting area. > > Regards, > Neil > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > > I think the SIP model is a very powerful > > model. It means that decisions about service invocation can always be > > represented as routing decisions. If I want some service from provider > > X, all that needs to happen is to have my call routed to the server at > > domain X. > > > > One of the reasons the separation between call control and service > > control was made in the IN, was the desire for the SCP not to receive > > all signaling messages for the call. I will note that in SIP, this > > function is already provided in the call signaling itself, through the > > Record-Route mechanism. This means an application server can drop out of > > the call after routing the initial request, as can a proxy. > > > > Is > > > it then logical to think about an implementation like the following : > > > > > > - The network server is a call stateful proxy (holding the state > of a > > > call between the INVITE and the BYE). This SIP proxy forward requests to > the > > > application server. This proxy server goes stateful and proxy requests > only > > > when needed (for instance when the end user has subscribed to predefined > > > services). > > > > Why? As I argue above, this distinction of an SSP/SCP role makes less > > sense in SIP. > > > > > - The application server will behave per call basis whether as a > > > redirect server (to provide routing services) or as a UAS when media > > > services are needed (IVR, ...). I am not sure whether this equipment > should > > > also proxy the request ?. > > > > If that is part of the service, sure. > > > > > - The goal here is not to involve the application server for the > whole > > > duration of the call but only when needed and this means telling the > > > application server what's state of the call that triggered the call of > the > > > service. For instance, A call B, but B is busy, the Proxy server of B > > > receives a 486 and then sends an INVITE to the feature server asking > what to > > > do. How to tell the application server that the user is busy (the > equivalent > > > of the DP Terminal busy of the IN) ? Should this be done in a > proprietary > > > way ? > > > > I would not do it this way. I would send the initial INVITE to the > > feature server, and when the 486 response comes, have it go from there. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 13:13:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04705 for ; Tue, 30 May 2000 13:13:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DBA3D4433C; Tue, 30 May 2000 13:03:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rayz.metatel.office (metatel.ne.mediaone.net [24.128.100.74]) by lists.bell-labs.com (Postfix) with ESMTP id 85D9144337 for ; Tue, 30 May 2000 13:03:46 -0400 (EDT) Received: from localhost (ray.zibman@localhost) by rayz.metatel.office (8.9.3/8.9.3) with ESMTP id NAA07262 for ; Tue, 30 May 2000 13:12:49 -0400 X-Authentication-Warning: rayz.metatel.office: ray.zibman owned process doing -bs Date: Tue, 30 May 2000 13:12:49 -0400 (EDT) From: Ray Zibman X-Sender: ray.zibman@rayz To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Allowing the user@host form on Via header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I propose the following changes to draft-ietf-sip-2543bis-00: Page 59, BNF of sent-by for Via header should read: sent-by = ([user@]host[:port])|(concealed-host) where user is as defined in Section 2, on page 18. Also, in section 4.2.6, page 28, description of Request-URI, delete the sentence "The user name MUST be empty." The reason for both changes is that we have a model in which a SIP Server is providing proxy services to a large collection of users. It often happens that a client belonging to user1 will send a SIP request such as an INVITE to this server. The server will receive this request and make various decisions according to logic installed on behalf of user1. This logic frequently requires stateful interactions. One decision could be to proxy the INVITE to the server for the invited party (user2). The proxy server for user2 is located on the same host (and same port) as the server for user1. The server for user2 may create the response to the INVITE or it may proxy it onwards to one or more clients for user2, or perhaps to other users that have been designated by user2. This is all according to logic installed on behalf of user2. When the response comes back to the server we want the server for user2 to see the response (and perhaps decide to proxy the request to SIP entities) before the response is seen by the server for user1. The addition of the user part in the sent-by of the via allows such a routing. If it is ever used in a situation where there is no concept of different servers for different users it is ignored. Note that the branch parameter does not meet our needs since there may, in fact, be no branching. Also, note that a common port on the SIP Server services all user agents, so the port parameter could not be used to differentiate servers for different users. And, there may be more users serviced on this host than could be separated with a typical 16 bit port number. The suggestion for removing the sentence about the user part in the Request-URI of REGISTER requests is similarly motivated. There is no reason given in the rfc why the user part MUST be empty in a Request-URI for REGISTER. In our model, a client will want to REGISTER itself with the server representing it within the SIP Server. In practice, it would be sufficient to use the From or To field of the REGISTER to determine which server should be used, but in a large system, where the servers might be distributed among many hosts (even though they are seen as a single SIP server host to the outside world) it is more efficient to use the Request-URI for routing purposes so we want the user name to be part of the Request-URI. Ray Zibman Senior Scientist MetaTel, Inc. 45 Rumford Ave. Waltham, MA 02453 (781) 392-2509 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 13:39:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05248 for ; Tue, 30 May 2000 13:39:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3542544337; Tue, 30 May 2000 13:30:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id ABF0C4434B for ; Tue, 30 May 2000 13:30:16 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id SAA26491; Tue, 30 May 2000 18:37:25 +0100 (BST) Message-ID: <3933FC55.373456F2@ubiquity.net> Date: Tue, 30 May 2000 18:37:25 +0100 From: Neil Deason 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 Subject: Re: [SIP] Allowing the user@host form on Via header References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ray Zibman wrote: > I propose the following changes to draft-ietf-sip-2543bis-00: > > Page 59, BNF of sent-by for Via header should read: > > sent-by = ([user@]host[:port])|(concealed-host) > > where user is as defined in Section 2, on page 18. > > Also, in section 4.2.6, page 28, description of Request-URI, delete the > sentence "The user name MUST be empty." Sorry, but I disagree. > The reason for both changes is that we have a model in which a SIP Server > is providing proxy services to a large collection of users. It often > happens that a client belonging to user1 will send a SIP request such as > an INVITE to this server. The server will receive this request and make > various decisions according to logic installed on behalf of user1. This > logic frequently requires stateful interactions. One decision could be to > proxy the INVITE to the server for the invited party (user2). The proxy > server for user2 is located on the same host (and same port) as the server > for user1. The server for user2 may create the response to the INVITE or > it may proxy it onwards to one or more clients for user2, or perhaps to > other users that have been designated by user2. This is all according to > logic installed on behalf of user2. When the response comes back to the > server we want the server for user2 to see the response (and perhaps > decide to proxy the request to SIP entities) before the response is seen > by the server for user1. The addition of the user part in the sent-by of > the via allows such a routing. If it is ever used in a situation where > there is no concept of different servers for different users it is > ignored. If I understand you correctly the response will come back to the right place as the 'two' servers are listening on the same host/port. Not associating the response with user2 is a local implementation issue. You could for example use a branch tag, doesn't matter if the request wasn't really forked, or even use a via-extension param. > Note that the branch parameter does not meet our needs since there may, in > fact, be no branching. Also, note that a common port on the SIP Server > services all user agents, so the port parameter could not be used to > differentiate servers for different users. And, there may be more users > serviced on this host than could be separated with a typical 16 bit port > number. > > The suggestion for removing the sentence about the user part in the > Request-URI of REGISTER requests is similarly motivated. There is no > reason given in the rfc why the user part MUST be empty in a Request-URI > for REGISTER. In our model, a client will want to REGISTER itself with > the server representing it within the SIP Server. In practice, it would > be sufficient to use the From or To field of the REGISTER to determine > which server should be used, but in a large system, where the servers > might be distributed among many hosts (even though they are seen as a > single SIP server host to the outside world) it is more efficient to use > the Request-URI for routing purposes so we want the user name to be part > of the Request-URI. There is a reason why the user part is empty, because the Request-URI names the domain of the registrar, not a user within a domain. If the information you require already is in the To header I don't think a change is necessary here either. hth, 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 May 30 13:50:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05515 for ; Tue, 30 May 2000 13:50:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E88264437E; Tue, 30 May 2000 13:41:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pop-rocks.shoretel.com (pop-rocks.shoretel.com [208.163.34.3]) by lists.bell-labs.com (Postfix) with ESMTP id 60E6C4437D for ; Tue, 30 May 2000 13:41:04 -0400 (EDT) Received: by pop-rocks.shoretel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 10:47:32 -0700 Message-ID: From: Amar Singh To: sip@lists.bell-labs.com Cc: Jonathan Rosenberg Date: Tue, 30 May 2000 10:47:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Call pickup Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Does SIP support Call pickup feature, if so where can I find details about it. thanks amar singh Shoreline 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 Tue May 30 14:00:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05723 for ; Tue, 30 May 2000 14:00:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6BF974437A; Tue, 30 May 2000 13:50:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id F276744340 for ; Tue, 30 May 2000 13:50:55 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id SAA02824; Tue, 30 May 2000 18:57:34 +0100 (BST) Message-ID: <3934010E.BD27F3D0@ubiquity.net> Date: Tue, 30 May 2000 18:57:34 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Amar Singh Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Call pickup References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit It can, see p.29 of the bis draft. If a registration is changed while a User Agent or Proxy Server processes an invitation, the new information SHOULD be used. hth, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net Amar Singh wrote: > Does SIP support Call pickup feature, if so where can I find details about > it. > > thanks > > amar singh > Shoreline 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 Tue May 30 14:01:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05823 for ; Tue, 30 May 2000 14:01:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A830A44396; Tue, 30 May 2000 13:51:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [207.104.210.242]) by lists.bell-labs.com (Postfix) with ESMTP id 187B444394 for ; Tue, 30 May 2000 13:51:05 -0400 (EDT) Received: by exchange.netrue.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 11:02:18 -0700 Message-ID: From: Tricia Wang To: sip@lists.bell-labs.com Date: Tue, 30 May 2000 11:02:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Domain or Zone concept Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, does SIP have Domain or Zone concept ? I would assume it does, cause I saw a Draft describing SIP interdomain architecture. If it does, how does it define a Domain or Zone ? by Register on a SIP Server ? By the way, is there a API for SIP network? I saw a Draft Java Servlet API but that's about it. Thank you for the time. Tricia NeTrue 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 Tue May 30 14:19:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06242 for ; Tue, 30 May 2000 14:19:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E34A4434B; Tue, 30 May 2000 14:10:10 -0400 (EDT) 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 C9E1944340 for ; Tue, 30 May 2000 14:10:07 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FVD00D01XJZ2F@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 30 May 2000 18:19:12 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FVD00D0CXJZ25@firewall.mcit.com>; Tue, 30 May 2000 18:19:11 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FVD00501XIWMP@dgismtp03.wcomnet.com>; Tue, 30 May 2000 18:18:33 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FVD00501XITM9@dgismtp03.wcomnet.com>; Tue, 30 May 2000 18:18:32 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0FVD002CUXIG2U@dgismtp03.wcomnet.com>; Tue, 30 May 2000 18:18:17 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Tue, 30 May 2000 18:18:55 +0000 Content-return: allowed Date: Tue, 30 May 2000 18:18:53 +0000 From: "Sinnreich, Henry" Subject: RE: [SIP] Domain or Zone concept To: "'Tricia Wang'" , sip@lists.bell-labs.com Message-id: <75C79E507864D3118AFC00805FEAB7D85B276F@ripexch001.mcit.com> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com >I saw a Draft describing SIP interdomain The draft assumes that a SIP proxy server within a domain controls the access to SIP services in that domain. The SIP proxy also controls access to QoS support by interacting with the policy server for that domain, to install policy in the network to support QoS for SIP calls. There is no notion of a "SIP Domain", since SIP services are only a subset of many other services in the same domain. The domain owns access to services and not vice versa. Henry >-----Original Message----- >From: Tricia Wang [mailto:TWang@NeTrue.com] >Sent: Tuesday, May 30, 2000 1:02 PM >To: sip@lists.bell-labs.com >Subject: [SIP] Domain or Zone concept > > >Hi, > does SIP have Domain or Zone concept ? >I would assume it does, cause I saw a Draft describing SIP interdomain >architecture. >If it does, how does it define a Domain or Zone ? by Register on a SIP >Server ? > > >By the way, is there a API for SIP network? I saw a Draft >Java Servlet API >but that's about it. > > >Thank you for the time. > >Tricia >NeTrue Communications Inc. > > > >_______________________________________________ >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 May 30 14:20:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06301 for ; Tue, 30 May 2000 14:20:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B4384443AD; Tue, 30 May 2000 14:10:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id CC72644394 for ; Tue, 30 May 2000 14:10:53 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id TAA08153; Tue, 30 May 2000 19:17:40 +0100 (BST) Message-ID: <393405C4.83614B08@ubiquity.net> Date: Tue, 30 May 2000 19:17:40 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tricia Wang Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Domain or Zone concept References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Still waiting for my ride home so I'll continue to try and give Jonathan a rest from having to answer everything... Tricia Wang wrote: > Hi, > does SIP have Domain or Zone concept ? > I would assume it does, cause I saw a Draft describing SIP interdomain > architecture. > If it does, how does it define a Domain or Zone ? by Register on a SIP > Server ? SIP domains are encapsulated within SIP URLs, e.g sip:user@domain. To find a sip server for a user you might do DNS query for a SIP Server associated with their domain. The Request-URI of a REGISTER also names the domain of a registration request. > By the way, is there a API for SIP network? I saw a Draft Java Servlet API > but that's about it. Not sure what exactly you mean by an API to a 'SIP network' but there are various contenders for service creation in a SIP network - CPL, Servlets SIP-CGI for example. Have a look around Henning's site, in particular .. http://www.cs.columbia.edu/%7Ehgs/sip/drafts_api.html There is also talk of JAIN/PARLAY interfaces to SIP exisiting in the future. hth, 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 May 30 14:30:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06436 for ; Tue, 30 May 2000 14:30:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 591E844395; Tue, 30 May 2000 14:21:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by lists.bell-labs.com (Postfix) with ESMTP id A449544340 for ; Tue, 30 May 2000 14:21:28 -0400 (EDT) Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA32F7; Tue, 30 May 2000 14:30:40 -0400 From: "Dave Oran" To: "charles Agboh" , "Dean Willis" , Cc: "Jonathan Rosenberg" Subject: RE: [SIP] Basic questions Date: Tue, 30 May 2000 14:30:31 -0400 Keywords: IETF Message-ID: 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) In-reply-to: <3933BCB1.8588EB31@helios.iihe.ac.be> Importance: Normal 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of charles Agboh > Sent: Tuesday, May 30, 2000 9:06 AM > To: Dean Willis; sip@lists.bell-labs.com > Cc: Jonathan Rosenberg > Subject: Re: [SIP] Basic questions > > > > Can somebody please answer the following question? " > > How can you have a "session" of any kind with only one participant? > > charles What is the sound of one hand clapping? SIP can set up Zen sessions. It's completely general. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 14:32:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06542 for ; Tue, 30 May 2000 14:32:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5EA5F443BA; Tue, 30 May 2000 14:21:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by lists.bell-labs.com (Postfix) with ESMTP id EB40E44340 for ; Tue, 30 May 2000 14:21:54 -0400 (EDT) Received: from l3107mxr.atl.hp.com (l3107mxr.atl.hp.com [15.19.254.19]) by atlrel1.hp.com (Postfix) with ESMTP id 01F1B14F9C; Tue, 30 May 2000 14:30:58 -0400 (EDT) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by l3107mxr.atl.hp.com (Postfix) with ESMTP id CE7F24FD8B; Tue, 30 May 2000 13:30:55 -0400 (EDT) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA24399; Tue, 30 May 2000 19:30:54 +0100 (BST) Message-ID: <39340931.6BE29A84@hplb.hpl.hp.com> Date: Tue, 30 May 2000 19:32:17 +0100 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tricia Wang Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Domain or Zone concept References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Tricia Wang wrote: > > Hi, > does SIP have Domain or Zone concept ? > I would assume it does, cause I saw a Draft describing SIP interdomain > architecture. > If it does, how does it define a Domain or Zone ? by Register on a SIP > Server ? I would say that the only concept of domains in vanilla SIP is really those of DNS. At a different level people talk about a particular providers network consituting a domain of its own, especially when discussing trust issues. Trust domains will obviously not generally map onto DNS domains one-to-one. > > By the way, is there a API for SIP network? I saw a Draft Java Servlet API > but that's about it. Right. That would be http://www.ietf.org/internet-drafts/draft-kristensen-sip-servlet-00.txt There will hopefully be an update of that draft sometime in the future (then I haven't said too much ;-). I did set up a mailing list for discussions related to the API (see http://com.hp.sip.listbot.com/) but it's been very quiet. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 14:46:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06837 for ; Tue, 30 May 2000 14:46:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 015B2443C3; Tue, 30 May 2000 14:36:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by lists.bell-labs.com (Postfix) with ESMTP id A46BA4438C for ; Tue, 30 May 2000 14:36:34 -0400 (EDT) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA23775; Tue, 30 May 2000 20:45:00 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([218.1.68.147]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id UAA11646; Tue, 30 May 2000 20:42:42 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2448.0) id ; Tue, 30 May 2000 20:47:49 +0200 Message-ID: <679076A067F2D211A8F70090274481B81515A0@LNN201E> From: Samandi Sami To: "'Neil Deason'" , Scott Hoffpauir Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP Application Server Date: Tue, 30 May 2000 20:47:31 +0200 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have no access to all the information of the softswitch app. WG, but if I have understood the explanation of Scott and what Jonathan answered to my first mail, it seems that both have the same point of view. An application server is involved in a call as any Proxy/redirect server/UAS and the invocation is made as any routing decision via an INVITE in the very beginning of the call. That's it. Please correct me if I am wrong Thank you Sami -----Original Message----- From: Neil Deason [SMTP:ndeason@ubiquity.net] Sent: mardi 30 mai 2000 18:39 To: Scott Hoffpauir Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server Thanks for providing the authoritive voice from the working group Scott. Scott Hoffpauir wrote: > The softswitch consortium applications working group is working on an > architecture supporting enhanced services in the softswitch network > architecture. An application server is introduced into the architecture to > host enhanced service logic and management functions. While a softswitch > provides basic call control and signaling, manages resources, and generates > call detail records, application servers are intended to host a variety of > enhanced services. Examples of enhanced services include calling card, 800 > number translation, Centrex, voice mail, and find-me services. SIP is used > as the interface between an application server and a softswitch. It allows a > softswitch to direct calls to an application server for enhanced services > processing and also allows an application server to redirect or transfer > calls back through a softswitch. > > An applications server can be a proxy, redirect server or user agent. It may > be stateful or stateless. It really depends on the applications being > provided. I've seen applications servers which are simple redirect servers > providing routing functions and more complex ones acting as back-to-back > user agents, providing unified messaging. Using SIP allows a softswitch (or > other end user device) to pass control to an application server, without > having to worry about its architecture or functions. My apologies if I am confusing the terms here but am I wrong in thinking that a SIP Proxy Server qualifies as a Softswitch? I have seen them described as such within the Softswitch Consortium. If a SIP Proxy is a Softswitch, isn't this approach in danger of reproducing the SSP/SCP model? Why would a Proxy Server need to pass an INVITE on to an Application Server for the AS to then proxy/redirect it? Couldn't SIP-CGI and CPL provide ways for a Proxy to access any service logic required to decide whether to proxy/redirect it directly. A Proxy Server augmented with service logic seems to be both a Softswitch and an Application Server, which would make defining an interface based on SIP between the two interesting. Regards, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > Jonathan Rosenberg wrote: > > > Samandi Sami wrote: > > > > > > Hello, > > > > > > Is there any document (or work) out there describing the distribution of > > > logic between a feature server (or application server) and the > underlying > > > network server asking for the services. > > The Softswitch consortium's Application Working Group are interested in this > area > you might want to also look into their work ... > http://www.softswitch.org/Working_Groups/application.html > > > It is true this is an implementation > > > issue but it is also true that this split of the roles between a SIP > > > application server and a SIP proxy server is similar to the IN > architecture > > > where the SSP handles the call control and the SCP the service control. > > > > The difference between and applications server and a proxy is only in > > the complexity of the programs which guide their operation. > > > > Both speak SIP; both can proxy or redirect; there is no way to > > distinguish a proxy from an applications server from the outside. This > > is quite different from the SSP/SCP model, which presumes totally > > different interfaces and roles. > > I am not part of the Softswitch Application Working Group, and certainly do > not > speak for them, but to me this doesn't appear to totally fit with what I > understand to be their position. I know there are people on this list close > to > this work, perhaps they would care to comment. > > The Softswitch Application Group are seeking to define the interfaces > between an > Application Server and a Softswitch. As I understand it a SIP Proxy Server > can be > one example of a Softswitch. They have described the Softswitch as providing > basic > call control and signalling, managing resources, and generating call detail > records. Whereas application servers host the service logic for a variety of > enhanced services and media servers provide bearer oriented functions, such > as > IVR, conferencing, and fax. They suggest SIP is used as the interface > between an > Application Server and a Softswitch, while the Real Time Protocol (RTP) is > used as > the interface between a media server and media gateway. > > Please note I am not seeking to promote the Softswitch view over the one > described > by Jonathan, which I personally empathise with, just some discussion of a > very > interesting area. > > Regards, > Neil > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > > I think the SIP model is a very powerful > > model. It means that decisions about service invocation can always be > > represented as routing decisions. If I want some service from provider > > X, all that needs to happen is to have my call routed to the server at > > domain X. > > > > One of the reasons the separation between call control and service > > control was made in the IN, was the desire for the SCP not to receive > > all signaling messages for the call. I will note that in SIP, this > > function is already provided in the call signaling itself, through the > > Record-Route mechanism. This means an application server can drop out of > > the call after routing the initial request, as can a proxy. > > > > Is > > > it then logical to think about an implementation like the following : > > > > > > - The network server is a call stateful proxy (holding the state > of a > > > call between the INVITE and the BYE). This SIP proxy forward requests to > the > > > application server. This proxy server goes stateful and proxy requests > only > > > when needed (for instance when the end user has subscribed to predefined > > > services). > > > > Why? As I argue above, this distinction of an SSP/SCP role makes less > > sense in SIP. > > > > > - The application server will behave per call basis whether as a > > > redirect server (to provide routing services) or as a UAS when media > > > services are needed (IVR, ...). I am not sure whether this equipment > should > > > also proxy the request ?. > > > > If that is part of the service, sure. > > > > > - The goal here is not to involve the application server for the > whole > > > duration of the call but only when needed and this means telling the > > > application server what's state of the call that triggered the call of > the > > > service. For instance, A call B, but B is busy, the Proxy server of B > > > receives a 486 and then sends an INVITE to the feature server asking > what to > > > do. How to tell the application server that the user is busy (the > equivalent > > > of the DP Terminal busy of the IN) ? Should this be done in a > proprietary > > > way ? > > > > I would not do it this way. I would send the initial INVITE to the > > feature server, and when the 486 response comes, have it go from there. _______________________________________________ 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 May 30 15:19:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07777 for ; Tue, 30 May 2000 15:19:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 25A874436F; Tue, 30 May 2000 15:10:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 6B53844340 for ; Tue, 30 May 2000 15:09:59 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA23694; Tue, 30 May 2000 15:19:04 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA22704; Tue, 30 May 2000 15:18:03 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 15:19:03 -0400 Message-ID: From: "Roy, Radhika R, ALARC" To: Anders Kristensen , Tricia Wang Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Domain or Zone concept Date: Tue, 30 May 2000 15:19:00 -0400 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Anders: Does it NOT mean that we should NOT use the term like "SIP Domain, SIP Intra-domain, or SIP Inter-Domain?" However, it appears that the terms like administrative domains, trust domains, inter-domain QoS, etc. as well as domains based on DNS are being used. Is there any way that we can use the term "domain" in a consistent way across all references? Best regards, Radhika R. Roy > -----Original Message----- > From: Anders Kristensen [SMTP:ak@hplb.hpl.hp.com] > Sent: Tuesday, May 30, 2000 2:32 PM > To: Tricia Wang > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Domain or Zone concept > > > Tricia Wang wrote: > > > > Hi, > > does SIP have Domain or Zone concept ? > > I would assume it does, cause I saw a Draft describing SIP interdomain > > architecture. > > If it does, how does it define a Domain or Zone ? by Register on a SIP > > Server ? > > I would say that the only concept of domains in vanilla SIP is really > those of DNS. At a different level people talk about a particular > providers network consituting a domain of its own, especially when > discussing trust issues. Trust domains will obviously not generally map > onto DNS domains one-to-one. > > > > > By the way, is there a API for SIP network? I saw a Draft Java Servlet > API > > but that's about it. > > Right. That would be > > http://www.ietf.org/internet-drafts/draft-kristensen-sip-servlet-00.txt > > There will hopefully be an update of that draft sometime in the future > (then I haven't said too much ;-). I did set up a mailing list for > discussions related to the API (see http://com.hp.sip.listbot.com/) but > it's been very quiet. > > Anders > > -- > Anders Kristensen , > http://www-uk.hpl.hp.com/people/ak/ > Hewlett-Packard Labs, Bristol, UK > > > _______________________________________________ > 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 May 30 15:39:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08593 for ; Tue, 30 May 2000 15:39:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F36654438C; Tue, 30 May 2000 15:30:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by lists.bell-labs.com (Postfix) with ESMTP id A79E844371 for ; Tue, 30 May 2000 15:30:04 -0400 (EDT) Received: from vovida.com (a98.vovida.com [209.237.8.98] (may be forged)) by repulse.cnchost.com id PAA26977; Tue, 30 May 2000 15:39:02 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <393418DA.F501B896@vovida.com> Date: Tue, 30 May 2000 12:39:06 -0700 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nishith Chudasama Cc: sip@lists.bell-labs.com Subject: Re: [SIP] OS support References: <20000530063833.7059.qmail@nw178.netaddress.usa.net> Content-Type: multipart/alternative; boundary="------------15E65F369EB87EFDDB174DCC" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------15E65F369EB87EFDDB174DCC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Which open souce SIP code do you have? The vovida open source SIP code has been ported to VXWORKS. Also, you may find more information in vovida mailing list sip@lists.vovida.com ; if you have questions specific to vovida SIP stack. Hope that helps sunitha Nishith Chudasama wrote: > Hi all, > > I am about to start working on the open source SIP code. > > Can anybody tell me, which all OSes are supported by the code except LINUX? > > I had an overview of the code and could find some lines with "#ifdef > VXWORKS". > Has this code been ported to VXWORKS? > > Thanks & 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 -- Sunitha Kumar http://www.vovida.com --------------15E65F369EB87EFDDB174DCC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Which open souce SIP code do you have?  The vovida open source SIP code  has been ported to VXWORKS.
 

Also, you may find more information in vovida mailing list  sip@lists.vovida.com ;   if you have questions specific to vovida SIP stack.

Hope that helps
sunitha
 

Nishith Chudasama wrote:

Hi all,

I am about to start working on the open source SIP code.

Can anybody tell me, which all OSes are supported by the code except LINUX?

I had an overview of the code and could find some lines with "#ifdef
VXWORKS".
Has this code been ported to VXWORKS?

Thanks & 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

-- 
Sunitha Kumar
http://www.vovida.com
  --------------15E65F369EB87EFDDB174DCC-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 16:26:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09649 for ; Tue, 30 May 2000 16:26:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C56C844371; Tue, 30 May 2000 16:17:34 -0400 (EDT) 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 10A6044340 for ; Tue, 30 May 2000 16:17:32 -0400 (EDT) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id PAA27977; Tue, 30 May 2000 15:26:29 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id PAA05561; Tue, 30 May 2000 15:26:28 -0500 (CDT) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA18076; Tue, 30 May 2000 15:26:27 -0500 (CDT) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id PAA12906; Tue, 30 May 2000 15:26:27 -0500 (CDT) Date: Tue, 30 May 2000 15:26:27 -0500 (CDT) Message-Id: <200005302026.PAA12906@b04a45.exu.ericsson.se> To: sip@lists.bell-labs.com, ray.zibman@metatel.com Subject: Re: [SIP] Allowing the user@host form on Via header X-Sun-Charset: US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Comments inline > I propose the following changes to draft-ietf-sip-2543bis-00: > > Page 59, BNF of sent-by for Via header should read: > sent-by = ([user@]host[:port])|(concealed-host) > where user is as defined in Section 2, on page 18. > > Also, in section 4.2.6, page 28, description of Request-URI, delete the > sentence "The user name MUST be empty." > > The reason for both changes is that we have a model in which a SIP Server > is providing proxy services to a large collection of users. It often > happens that a client belonging to user1 will send a SIP request such as > an INVITE to this server. The server will receive this request and make > various decisions according to logic installed on behalf of user1. This > logic frequently requires stateful interactions. One decision could be to > proxy the INVITE to the server for the invited party (user2). The proxy > server for user2 is located on the same host (and same port) as the server > for user1. The server for user2 may create the response to the INVITE or > it may proxy it onwards to one or more clients for user2, or perhaps to > other users that have been designated by user2. This is all according to > logic installed on behalf of user2. When the response comes back to the > server we want the server for user2 to see the response (and perhaps > decide to proxy the request to SIP entities) before the response is seen > by the server for user1. The addition of the user part in the sent-by of > the via allows such a routing. If it is ever used in a situation where > there is no concept of different servers for different users it is > ignored. > > Note that the branch parameter does not meet our needs since there may, in > fact, be no branching. Also, note that a common port on the SIP Server > services all user agents, so the port parameter could not be used to > differentiate servers for different users. And, there may be more users > serviced on this host than could be separated with a typical 16 bit port > number. > You would only need to play these games if the proxy you are referring to is transaction-stateless. If it is NOT transaction-stateless, then it is a trivial matter to add the user information from the Request-URI to the transaction state you are already maintaining. Frankly for the application you have in mind, it makes more sense to use a stateful proxy than to try and change the way SIP Via: handling works. (Though I think your use of the term "proxy" is a little different from what I mean given your assumption that you have two proxies on the same machine using the same port; in your case, the routing you are doing seems to be an internal application decision and doesn't need to be explicitly handled by the SIP protocol) > The suggestion for removing the sentence about the user part in the > Request-URI of REGISTER requests is similarly motivated. There is no > reason given in the rfc why the user part MUST be empty in a Request-URI > for REGISTER. In our model, a client will want to REGISTER itself with > the server representing it within the SIP Server. In practice, it would > be sufficient to use the From or To field of the REGISTER to determine > which server should be used, but in a large system, where the servers > might be distributed among many hosts (even though they are seen as a > single SIP server host to the outside world) it is more efficient to use > the Request-URI for routing purposes so we want the user name to be part > of the Request-URI. > Though I don't agree with this statement, I do agree that the user name should be allowed in the Request-URI. > Ray Zibman > Senior Scientist > MetaTel, Inc. > 45 Rumford Ave. > Waltham, MA 02453 > (781) 392-2509 > -- Sean Olson tel: 972-583-5472 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 16:27:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09678 for ; Tue, 30 May 2000 16:27:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F38D443A8; Tue, 30 May 2000 16:17:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by lists.bell-labs.com (Postfix) with ESMTP id 11BB5443A5 for ; Tue, 30 May 2000 16:17:36 -0400 (EDT) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel1.hp.com (Postfix) with ESMTP id CB7354E81 for ; Tue, 30 May 2000 12:39:43 -0700 (PDT) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id UAA18698; Tue, 30 May 2000 20:39:30 +0100 (BST) Message-ID: <39341946.84CBE6DC@hplb.hpl.hp.com> Date: Tue, 30 May 2000 20:40:54 +0100 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALARC" Cc: Tricia Wang , sip@lists.bell-labs.com Subject: Re: [SIP] Domain or Zone concept References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Roy, Radhika R, ALARC" wrote: > > Hi, Anders: > > Does it NOT mean that we should NOT use the term like "SIP Domain, SIP > Intra-domain, or SIP Inter-Domain?" Yes, FWIW I don't think those terms are well-defined and thus should be qualified somehow. > > However, it appears that the terms like administrative domains, trust > domains, inter-domain QoS, etc. as well as domains based on DNS are being > used. Right, but in these cases the qualifications of the term "domain" gives some sort of idea of what's meant, so that's more reasonable. > > Is there any way that we can use the term "domain" in a consistent way > across all references? Just because RFC2543 doesn't talk about administrative domains doesn't mean they are not important. I don't think there is any need for a language police looking after how these terms are used (which is probably not what you meant either), except to encourage people to be clear about what they mean when they use them. I feel a quote coming on... "Simplicity, clarity, singleness: These are the attributes that give our lives power and vividness and joy as they are also the marks of great art." -- Richard Holloway just looked that up. Should be in the SIP spec, really ;-) Anders > > Best regards, > Radhika R. Roy > > > -----Original Message----- > > From: Anders Kristensen [SMTP:ak@hplb.hpl.hp.com] > > Sent: Tuesday, May 30, 2000 2:32 PM > > To: Tricia Wang > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Domain or Zone concept > > > > > > Tricia Wang wrote: > > > > > > Hi, > > > does SIP have Domain or Zone concept ? > > > I would assume it does, cause I saw a Draft describing SIP interdomain > > > architecture. > > > If it does, how does it define a Domain or Zone ? by Register on a SIP > > > Server ? > > > > I would say that the only concept of domains in vanilla SIP is really > > those of DNS. At a different level people talk about a particular > > providers network consituting a domain of its own, especially when > > discussing trust issues. Trust domains will obviously not generally map > > onto DNS domains one-to-one. > > > > > > > > By the way, is there a API for SIP network? I saw a Draft Java Servlet > > API > > > but that's about it. > > > > Right. That would be > > > > http://www.ietf.org/internet-drafts/draft-kristensen-sip-servlet-00.txt > > > > There will hopefully be an update of that draft sometime in the future > > (then I haven't said too much ;-). I did set up a mailing list for > > discussions related to the API (see http://com.hp.sip.listbot.com/) but > > it's been very quiet. > > > > Anders > > -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 17:56:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11365 for ; Tue, 30 May 2000 17:56:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D919A44340; Tue, 30 May 2000 17:47:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6017F4433C for ; Tue, 30 May 2000 17:47:40 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA03918; Tue, 30 May 2000 17:54:12 -0400 (EDT) Message-ID: <39343B3E.738D12A@dynamicsoft.com> Date: Tue, 30 May 2000 18:05:50 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Henning Schulzrinne , "Adam B. Roach" , sip@lists.bell-labs.com Subject: Re: [SIP] Contact in OPTIONS References: <003001bfca12$ea210d80$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > Gentlemen, > > > > > Presumably, this function (TCP/UDP translation) would be provided > > > > only if the clients couldn't talk to each other directly (e.g. > > > > one is TCP only, and the other is UDP only). In this case, the > > > > proxy must remain in the path to continue to provide TCP/UDP > > > > translation for the duration of the call leg. > > > > > > Since then, some additional discussion seems to indicate that things > > > get a lot easier if we require UAs to speak UDP as the lingua franca. > > > Otherwise, we can't satisfy the goal of simply plugging in a bunch of > > > SIP phones and setting up calls, without a proxy. > > So are we saying that adding a Record-Route header is not necessary > just because a proxy is acting as a TCP/UDP bridge? Yes. > > > To be specific, the proposal is that UDP support in UA transition from > > SHOULD to MUST, so that: > > > > 1. UAs SHOULD support TCP, MUST support UDP > > 2. proxies MUST support TCP and UDP > > > > The transport parameter in the Contact and Record-Route headers then > > becomes the preferential choice; if not supported, you can always fall > > back to UDP. > > Hmmm... isn't the implication of this that servers should ensure > that for every TCP port listened on (apologies for the > socket-oriented terminology), they have also bound a UDP socket > with the same port number? Furthermore, these ports should have > the same semantics? (I can imagine a proxy that exhibits different > behaviour on different ports.) Yes, I suppose this is the implication. This is needed even if you assume everyone doesn't speak UDP, and then proxies which translate must record-route. > > Is this ever going to be a problem? (I suspect not, but it prob. > needs to be stated, if not already.) If you want different behavior on different ports, thats fine. All it means is that on a particular port, the behavior for UDP and TCP would need to be the same. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 17:58:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11431 for ; Tue, 30 May 2000 17:58:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5756443A5; Tue, 30 May 2000 17:49:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 63AE2443A2 for ; Tue, 30 May 2000 17:49:39 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA03966; Tue, 30 May 2000 18:00:02 -0400 (EDT) Message-ID: <39343C9C.F79563C0@dynamicsoft.com> Date: Tue, 30 May 2000 18:11:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Plong@smithmicro.com Cc: dwillis@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <000b01bfca41$99f4b760$6701a8c0@plong> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Plong@smithmicro.com wrote: > > Dean, > > So is this statement incorrect? Section 1.3: "A session as defined for SDP > can comprise one or more RTP sessions." This is a different question. I think SDP requires a single m line, although I think this has also been the subject of some discussion... -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 18:00:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11494 for ; Tue, 30 May 2000 18:00:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 80C29443BD; Tue, 30 May 2000 17:51:37 -0400 (EDT) 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 48E48443B7 for ; Tue, 30 May 2000 17:51:34 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id EAA05995; Wed, 31 May 2000 04:02:55 -0500 Message-Id: <200005310902.EAA05995@kevlar.softarmor.com> Date: Tue, 30 May 2000 17:03:05 -0500 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Plong@smithmicro.com Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <000b01bfca41$99f4b760$6701a8c0@plong> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The statement is CORRECT -- a session can comprise one or more RTP sessions. However, it is not COMPLETE -- a session can comprise one or more network sessions of any sort established by SIP, including RTP and other protocols. Historically, there has been great interest in using SIP for voice communications, hence the emphasis on SDP. But from a design perspective, it is not limited to RTP. Foe example, I saw last year a demo of Quake initiation using SIP. -- Dean Plong@smithmicro.com wrote: > > Dean, > > So is this statement incorrect? Section 1.3: "A session as defined for SDP > can comprise one or more RTP sessions." > > Paul Long (an admitted hair splitter) > Smith Micro Software, Inc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 18:12:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11777 for ; Tue, 30 May 2000 18:12:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB31C44396; Tue, 30 May 2000 18:03:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 496CE44395 for ; Tue, 30 May 2000 18:03:04 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA04023; Tue, 30 May 2000 18:09:37 -0400 (EDT) Message-ID: <39343EDC.2B4005FD@dynamicsoft.com> Date: Tue, 30 May 2000 18:21:16 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Scott Hoffpauir , sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: <3933EEB2.893C06AB@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil Deason wrote: > > > An applications server can be a proxy, redirect server or user agent. It may > > be stateful or stateless. It really depends on the applications being > > provided. I've seen applications servers which are simple redirect servers > > providing routing functions and more complex ones acting as back-to-back > > user agents, providing unified messaging. Using SIP allows a softswitch (or > > other end user device) to pass control to an application server, without > > having to worry about its architecture or functions. > > My apologies if I am confusing the terms here but am I wrong in thinking that a > SIP Proxy Server qualifies as a Softswitch? I have seen them described as such > within the Softswitch Consortium. If a SIP Proxy is a Softswitch, isn't this > approach in danger of reproducing the SSP/SCP model? Why would a Proxy Server > need to pass an INVITE on to an Application Server for the AS to then > proxy/redirect it? Couldn't SIP-CGI and CPL provide ways for a Proxy to access > any service logic required to decide whether to proxy/redirect it directly. A > Proxy Server augmented with service logic seems to be both a Softswitch and an > Application Server, which would make defining an interface based on SIP between > the two interesting. This leads back to my original statement. The only difference between a proxy (I won't get into the softswitch vs. proxy thing, which is purely a definition issue) and an application server is the complexity of the programs it executes. In the case you describe, of a proxy implementing CGI or CPL or JAIN or parlay or whatever apps, it is then an app server. One could even argue that the proxy function is a type of application running on an app server. Fact is, it doesn't really matter. Samandi Sami later writes: > I have no access to all the information of the softswitch app. WG, but if I > have understood the explanation of Scott and what Jonathan answered to my > first mail, it seems that both have the same point of view. An application > server is involved in a call as any Proxy/redirect server/UAS and the > invocation is made as any routing decision via an INVITE in the very > beginning of the call. That's it. Yes. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 18:16:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11856 for ; Tue, 30 May 2000 18:16:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92E2C443C9; Tue, 30 May 2000 18:07:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0F330443C8 for ; Tue, 30 May 2000 18:06:59 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA04031; Tue, 30 May 2000 18:13:42 -0400 (EDT) Message-ID: <39343FD1.7BB4EBFF@dynamicsoft.com> Date: Tue, 30 May 2000 18:25:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: sip Subject: Re: [SIP] wg last call on reliable provisional responses References: <003101bfca17$1de7eae0$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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > Hi, > > (SIP List: Apologies for the use of "Gentlemen" in my last post; > very poor indeed.) > > > I've just submitted an updated version of the I-D on "Reliability of > > Provisional Responses in SIP". Until it appears in the archives, you > > can find a copy at: > [...] > > Well it's certainly easier for a proxy than the original draft (00). > Which makes me happy. &:) > > One thing I'm a little confused about: Section 5.2 (UAS Behavior) > contains the following text: > "Note that a UAS can send reliable provisional responses > for any request, including a PRACK request. It is anticipated > that reliable provisional responses will be most useful for > INVITE requests." > Is allowing a PRACK to be responded to with reliable provisional > responses potentially a big old nightmare? Only if you implement it wrong ;) The whole idea is that PRACK is a request, like any other. If you don't treat it differently than any other request, in terms of its ability to be responded to, you have no problem. However, if people want to nix the ability to send reliable provisional responses to PRACK itself, I am willing to discuss. I doubt its useful. Or am I just being a > little bit dull, really? Also, shouldn't it be stated that > reliable provisional responses can't be used with ACK? ACK can never have responses; this draft doesn't change that. I don't think its confusing, but I'll add some verbiage to that effect. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 18:23:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11935 for ; Tue, 30 May 2000 18:23:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF764443CF; Tue, 30 May 2000 18:13:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 622B6443C7 for ; Tue, 30 May 2000 18:13:45 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA04084; Tue, 30 May 2000 18:24:09 -0400 (EDT) Message-ID: <39344243.55686D34@dynamicsoft.com> Date: Tue, 30 May 2000 18:35:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Berggren Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Comment on section 6.34.3 in rfc2543bis References: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Lars Berggren wrote: > > I quote: > "We define the calling URI as the URI found in the Contact header of the > request from the calling UA, if present, or the From header, if there is > no Contact header. The called UA copies the Record-Route entries, > maintaining their ordering, to the Route header field. However, all > components except the maddr parameter are replaced by the > calling URI." > > As I interpret this, a proxy can not specify which port or the transport > protocol it wants to be used in subsequent requests from the called UA > since the only parameter of the url of the proxy that is reflected in the > Route-list is maddr. Is this correct? Actually, I think this should include port and transport (although as per other threads the transport is not terribly critical, more a preference for a first try). > > What about rr-extension, is it supposed to be copied into the route field > as a route-extension or is that supposed to be defined by the extension? THis came up at the bakeoff. Copying it into the Route header doesn't help, since that Route header is stripped off before getting back to the person who inserted it. Thus, you can put something into Record-Route, but you won't get it back in Route. This is what the State header in DCS is for. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 18:56:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12472 for ; Tue, 30 May 2000 18:56:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F32C44351; Tue, 30 May 2000 18:46:58 -0400 (EDT) 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 83E604433C for ; Tue, 30 May 2000 18:46:55 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 30 18:54:22 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6577344344; Tue, 30 May 2000 18:41:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 3F2F844341 for ; Tue, 30 May 2000 18:41:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C142952C4; Tue, 30 May 2000 18:41:29 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5DFEE52AB for ; Tue, 30 May 2000 18:41:26 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 30 18:40:02 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue May 30 18:40:01 EDT 2000 Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA04173; Tue, 30 May 2000 18:41:20 -0400 (EDT) Message-ID: <3934464A.1BAB9D49@dynamicsoft.com> Date: Tue, 30 May 2000 18:52:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: kbinu@hss.hns.com Cc: Gonzalo Camarillo , sip Subject: Re: [SIP] Retransmissions References: <652568EF.0045CA83.00@sampark.hss.hns.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit kbinu@hss.hns.com wrote: > > >So, if a server receives an INVITE and it responses with 400 for > >instance. If a CANCEL is received, it will stop sending the 400 and it > >will send the 487. It will retransmit the 487 until the ACK for the > >INVITE arrives. Does the retransmission counter get re-started (the > >server might have retransmitted already some times the 400 response)? > > So the correct behaviour here would be to stop the 400 response > retransmissions for the INVITE and answer the CANCEL with a 200 OK. The > server would send a 487 if the cancelled INVITE happens to come by and not > otherwise. No, no, no. This section of the bis draft has not changed, but it will. We have discussed this on the list extensively. If you receive a request, and you haven't yet sent a final response, and then a CANCEL comes, respond to the CANCEL with 200 OK, and the original request with 487. Continue to retransmit that 487 as you normally would , even if a BYE comes. If you've already responded to a request with a final response, and then a CANCEL comes, respond to the CANCEL with 200 OK, and thats it. Continue with processing the final response to that request independently of the CANCEL. No matter what, don't ever start sending one final response, and then change to a different once when CANCEL comes. Very bad. The idea here is that CANCEL is a separate transaction, which basically says "respond to this original request with 487 if you haven't already, otherwise don't do anything special". The CANCEL and the transaction it cancels still complete normally. No matter what, each transaction should execute and complete normally, independent of any other. This includes the case where you get an INVITE, and then a BYE. Respond to the INVITE with a 487 (or something), and then respond to the BYE with 200 OK. Both the INVITE and BYE transactions complete normally. We are in the process of updating this diagram to reflect this. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 30 19:20:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12825 for ; Tue, 30 May 2000 19:20:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D780944384; Tue, 30 May 2000 19:11:20 -0400 (EDT) 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 F371E44336 for ; Tue, 30 May 2000 19:11:17 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id FAA06256 for ; Wed, 31 May 2000 05:22:42 -0500 Message-Id: <200005311022.FAA06256@kevlar.softarmor.com> Date: Tue, 30 May 2000 18:22:53 -0500 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com References: <000b01bfca41$99f4b760$6701a8c0@plong> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Co-chair Dean's New Mailing Address Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit As some of you may have noticed, my office mailing address is now: dwillis@dynamicsoft.com However, you may also see me writing from (or send mail to me at) dean.willis@softarmor.com dwillis@softarmor.com dwillis@greycouncil.com -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue May 30 20:28:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13774 for ; Tue, 30 May 2000 20:28:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A8AE14438E; Tue, 30 May 2000 20:18:59 -0400 (EDT) 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 59BFA44336 for ; Tue, 30 May 2000 20:18:55 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue May 30 20:26:31 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D6F0144344; Tue, 30 May 2000 20:13:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id A696144341 for ; Tue, 30 May 2000 20:13:21 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 35A4152C4; Tue, 30 May 2000 20:13:30 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4EE0552B6 for ; Tue, 30 May 2000 20:13:27 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 30 20:12:06 EDT 2000 Received: from cybertron.div8.net ([24.42.217.5]) by dusty; Tue May 30 20:12:06 EDT 2000 Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.research.bell-labs.com; Tue, 30 May 2000 20:11:45 -0400 (EDT) Date: Tue, 30 May 2000 20:11:45 -0400 From: Billy Biggs To: Jonathan Rosenberg Cc: kbinu@hss.hns.com, Gonzalo Camarillo , sip Subject: Re: [SIP] Retransmissions Message-ID: <20000530201145.A19699@div8.net> References: <652568EF.0045CA83.00@sampark.hss.hns.com> <3934464A.1BAB9D49@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3934464A.1BAB9D49@dynamicsoft.com>; from jdrosen@dynamicsoft.com on Tue, May 30, 2000 at 06:52:58PM -0400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenberg (jdrosen@dynamicsoft.com): > The idea here is that CANCEL is a separate transaction, which basically > says "respond to this original request with 487 if you haven't already, > otherwise don't do anything special". The CANCEL and the transaction it > cancels still complete normally. No matter what, each transaction should > execute and complete normally, independent of any other. > > This includes the case where you get an INVITE, and then a BYE. Respond > to the INVITE with a 487 (or something), and then respond to the BYE > with 200 OK. Both the INVITE and BYE transactions complete normally. I do hate to beat on this more, but... In the case where you get an INVITE and then a BYE with a higher CSeq, it seems really silly to have to keep around state for both of these transactions on the call leg. Why bother with the INVITE transaction at all? The far end has cancelled it anyways? That just seems like more unnecessary state to keep in my code. It seems more important to me to worry about keeping the endpoints simple rather than the proxies, otherwise it's going to take everyone alot longer to implement good clients. Proxies can afford more bloat than endpoints: let them time out or be smarter with the CSeqs. Any proxy that cares that much about old transaction state is likely subject to alot of DoS attacks anyways. Since that argument will likely get me nowhere, please hear the message that I would like to see simpler endpoint requirements. -- 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 Wed May 31 00:02:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17742 for ; Wed, 31 May 2000 00:02:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92F2A44337; Tue, 30 May 2000 23:52:55 -0400 (EDT) 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 191D744336 for ; Tue, 30 May 2000 23:52:53 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 31 00:00:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7400844344; Tue, 30 May 2000 23:47:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 452CD44341 for ; Tue, 30 May 2000 23:47:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B7F5A52C4; Tue, 30 May 2000 23:47:28 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C3A6B52B6 for ; Tue, 30 May 2000 23:47:25 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue May 30 23:46:15 EDT 2000 Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue May 30 23:46:14 EDT 2000 Received: from dynamicsoft.com (1Cust20.tnt1.freehold.nj.da.uu.net [63.17.113.20]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA04706; Tue, 30 May 2000 23:47:32 -0400 (EDT) Message-ID: <39348AFF.56363A88@dynamicsoft.com> Date: Tue, 30 May 2000 23:46:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: kbinu@hss.hns.com, Gonzalo Camarillo , sip Subject: Re: [SIP] Retransmissions References: <652568EF.0045CA83.00@sampark.hss.hns.com> <3934464A.1BAB9D49@dynamicsoft.com> <20000530201145.A19699@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Jonathan Rosenberg (jdrosen@dynamicsoft.com): > > > The idea here is that CANCEL is a separate transaction, which basically > > says "respond to this original request with 487 if you haven't already, > > otherwise don't do anything special". The CANCEL and the transaction it > > cancels still complete normally. No matter what, each transaction should > > execute and complete normally, independent of any other. > > > > This includes the case where you get an INVITE, and then a BYE. Respond > > to the INVITE with a 487 (or something), and then respond to the BYE > > with 200 OK. Both the INVITE and BYE transactions complete normally. > > I do hate to beat on this more, but... > > In the case where you get an INVITE and then a BYE with a higher CSeq, > it seems really silly to have to keep around state for both of these > transactions on the call leg. Why bother with the INVITE transaction at > all? The far end has cancelled it anyways? That just seems like more > unnecessary state to keep in my code. Its good for UAs, and really good for proxies. For the UA, it allows for independence of transactions, and separation of transaction processing from call state. I would argue that requiring the INVITE transaction to cease For proxies, which don't see call state in many cases, it allows for independent operation of each transaction. Without that, proxies will be left with state hanging around (i.e., INVITE transaction state) when the BYE comes, particularly when the proxy doesn't even see the BYE. This leads to wasted resources in proxies, performance bottlenecks, and more complex code to clean up. > > It seems more important to me to worry about keeping the endpoints > simple rather than the proxies, otherwise it's going to take everyone > alot longer to implement good clients. Proxies can afford more bloat > than endpoints: let them time out or be smarter with the CSeqs. I disagree completely. What you are suggesting is at odds with the entire IP model of scalability (and with the model supported by SIP), which says to push complexity to the edge, where it is easier to manage. In any case, this detail of completing INVITE transactions hardly qualifies as complex. As I argue above, I think it makes things simpler. > > Any proxy that cares that much about old transaction state is likely > subject to alot of DoS attacks anyways. You want your protocols to clean up state under normal operation. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 31 00:10:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17829 for ; Wed, 31 May 2000 00:10:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0973344358; Wed, 31 May 2000 00:00:56 -0400 (EDT) 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 56D6744356 for ; Wed, 31 May 2000 00:00:53 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 31 00:08:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id CBB0B44345; Tue, 30 May 2000 23:55:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id 9247A44341 for ; Tue, 30 May 2000 23:55:20 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4250C52C4; Tue, 30 May 2000 23:55:27 -0400 (EDT) Delivered-To: sip@lists.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 6E7D152B6 for ; Tue, 30 May 2000 23:55:24 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue May 30 23:54:46 EDT 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Tue May 30 23:54:44 EDT 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id JAA08588; Wed, 31 May 2000 09:48:07 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568F0.00143A9B ; Wed, 31 May 2000 09:10:57 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Billy Biggs Cc: Jonathan Rosenberg , kbinu@hss.hns.com, Gonzalo Camarillo , sip Message-ID: <652568F0.0014391E.00@sampark.hss.hns.com> Date: Wed, 31 May 2000 09:10:53 +0530 Subject: Re: [SIP] Retransmissions 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com On the contrary, the fact that I let all transactions complete their normal way has imho, made our client development much easier. This has meant that our transaction request-response code remains usually intact, and hence, we do not really have to maintain cross-related state - only one transaction state and still be able to support BYE and more importantly CANCEL. Further, there is a bigger issue for not having the transaction complete as you mention. Lets suppose client A sends an INVITE to client B through proxy P. Now again, lets assume that B returned A a contact address for further requests - which happens to be the direct address of B. Then that would mean that A would send its future request directly to B without P (Assuming a simple proxy that does not do record-route). What would then happen is that when A sent a BYE directly to B , the proxy would have no idea that the pending transaction of INVITE is no longer valid - and would not have any option but to wait for a regular timeout to happen before it could flush the old INVITE out. This is certainly not a good situation. The beauty, imho, of letting *all* transactions complete is that no inbetween node is left hanging in between a transaction state unnecessarily. The merits of transaction completeness, I feel, over-weigh message optimisation. Regs Arjun -- Arjun Roychowdhury @ Hughes Software Systems Billy Biggs wrote: I do hate to beat on this more, but... In the case where you get an INVITE and then a BYE with a higher CSeq, it seems really silly to have to keep around state for both of these transactions on the call leg. Why bother with the INVITE transaction at all? The far end has cancelled it anyways? That just seems like more unnecessary state to keep in my code. It seems more important to me to worry about keeping the endpoints simple rather than the proxies, otherwise it's going to take everyone alot longer to implement good clients. Proxies can afford more bloat than endpoints: let them time out or be smarter with the CSeqs. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 01:49:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23968 for ; Wed, 31 May 2000 01:49:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 35A8844346; Wed, 31 May 2000 01:40:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from paris.mds.local (rdu162-228-050.nc.rr.com [24.162.228.50]) by lists.bell-labs.com (Postfix) with ESMTP id 1995744336 for ; Wed, 31 May 2000 01:40:09 -0400 (EDT) Received: from berlin (berlin.mds.local [192.168.1.4]) by paris.mds.local (8.8.7/8.8.7) with SMTP id BAA03410; Wed, 31 May 2000 01:49:22 -0400 Message-ID: <019501bfcac3$f8e00e50$0401a8c0@mds.local> From: "Paul E. Jones" To: "Jonathan Rosenberg" , Cc: , References: <000b01bfca41$99f4b760$6701a8c0@plong> <39343C9C.F79563C0@dynamicsoft.com> Subject: Re: [SIP] Basic questions Date: Wed, 31 May 2000 01:49:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, SDP does not mandate a single m= line. Am I missing something? It's perfectly valid to do this in SDP I believe: m=audio 2500 RTP/AVP 0 m=video 2502 RTP/AVP 31 The ABNF grammar allows it and there are several examples in RFC 2327. Paul ----- Original Message ----- From: "Jonathan Rosenberg" To: Cc: ; Sent: Tuesday, May 30, 2000 6:11 PM Subject: Re: [SIP] Basic questions > > > Plong@smithmicro.com wrote: > > > > Dean, > > > > So is this statement incorrect? Section 1.3: "A session as defined for SDP > > can comprise one or more RTP sessions." > > This is a different question. I think SDP requires a single m line, > although I think this has also been the subject of some discussion... > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Wed May 31 01:50:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23983 for ; Wed, 31 May 2000 01:50:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3ABA044373; Wed, 31 May 2000 01:40:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 005ED44336 for ; Wed, 31 May 2000 01:40:26 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id LAA02233 for ; Wed, 31 May 2000 11:17:27 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 31 May 2000 11:17:26 +0000 (IST) Received: from localhost (srinath@localhost) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id LAA20244 for ; Wed, 31 May 2000 11:17:28 +0530 (IST) Date: Wed, 31 May 2000 11:17:28 +0530 (IST) From: A Srinath To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Retransmissions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan D. Rosenberg wrote If you've already responded to a request with a final response, and then a CANCEL comes, respond to the CANCEL with 200 OK, and thats it. Continue with processing the final response to that request independently of the CANCEL. Dont we have to send a 481 response to the CANCEL as the earlier transaction has been completed as a final response has already been sent. In the same case if the server were a proxy, then does it not forward the CANCEL downstream too? Srinath A Silicon Automation Systems Phone: 5276100, 5276108 extn 4220 #1309, 10th Main, HAL III Stage Bangalore 560 008, India _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 01:56:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24003 for ; Wed, 31 May 2000 01:56:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 030624439D; Wed, 31 May 2000 01:47:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E27024438B for ; Wed, 31 May 2000 01:47:12 -0400 (EDT) Received: from dynamicsoft.com (1Cust20.tnt1.freehold.nj.da.uu.net [63.17.113.20]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA04783; Wed, 31 May 2000 01:57:23 -0400 (EDT) Message-ID: <3934A96D.C353848A@dynamicsoft.com> Date: Wed, 31 May 2000 01:55:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Paul E. Jones" Cc: Plong@smithmicro.com, dwillis@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <000b01bfca41$99f4b760$6701a8c0@plong> <39343C9C.F79563C0@dynamicsoft.com> <019501bfcac3$f8e00e50$0401a8c0@mds.local> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sorry; I meant at least a single m line (i.e., zero m lines not allowed). -Jonathan R. "Paul E. Jones" wrote: > > Jonathan, > > SDP does not mandate a single m= line. Am I missing something? It's > perfectly valid to do this in SDP I believe: > > m=audio 2500 RTP/AVP 0 > m=video 2502 RTP/AVP 31 > > The ABNF grammar allows it and there are several examples in RFC 2327. > > Paul > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: > Cc: ; > Sent: Tuesday, May 30, 2000 6:11 PM > Subject: Re: [SIP] Basic questions > > > > > > > Plong@smithmicro.com wrote: > > > > > > Dean, > > > > > > So is this statement incorrect? Section 1.3: "A session as defined for > SDP > > > can comprise one or more RTP sessions." > > > > This is a different question. I think SDP requires a single m line, > > although I think this has also been the subject of some discussion... > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 May 31 03:17:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01183 for ; Wed, 31 May 2000 03:17:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D012A44337; Wed, 31 May 2000 03:08:42 -0400 (EDT) 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 4E0CC44336 for ; Wed, 31 May 2000 03:08:39 -0400 (EDT) Received: by jupiter.matranortel.com; id JAA17941; Wed, 31 May 2000 09:17:47 +0200 (CEST) Message-Id: <200005310717.JAA17941@jupiter.matranortel.com> Date: Wed, 31 May 2000 09:19:25 +0200 From: Dubois X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , SIP Subject: Re: [SIP] Basic questions References: <000b01bfca41$99f4b760$6701a8c0@plong> <39343C9C.F79563C0@dynamicsoft.com> <019501bfcac3$f8e00e50$0401a8c0@mds.local> <200005310556.HAA13629@jupiter.matranortel.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, If you need to have at least a single m line, why is it written page 8 of the RFC 2327 (SDP) that you can have ZERO or more media descriptions ? -Alain Jonathan Rosenberg wrote: > Sorry; I meant at least a single m line (i.e., zero m lines not > allowed). > > -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 Wed May 31 03:54:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01416 for ; Wed, 31 May 2000 03:54:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C83924438B; Wed, 31 May 2000 03:45:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id BDC9D44336 for ; Wed, 31 May 2000 03:45:35 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id IAA22311; Wed, 31 May 2000 08:52:50 +0100 (BST) Message-ID: <3934C4D3.99C0DC5@ubiquity.net> Date: Wed, 31 May 2000 08:52:51 +0100 From: James Undery X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Jo Hornsby , sip Subject: Re: [SIP] wg last call on reliable provisional responses References: <003101bfca17$1de7eae0$4e34c3c1@ubiquity.co.uk> <39343FD1.7BB4EBFF@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Jo Hornsby wrote: > > > > Is allowing a PRACK to be responded to with reliable provisional > > responses potentially a big old nightmare? > > Only if you implement it wrong ;) I think what is being hinted at albeit subtlety is, is the transaction ever going to end? (The Halting Problem.) Although I can't think of a case off hand where you'd want to provisionally respond to a PRACK, specifically allowing it is just asking for trouble between legitimate implementations. > > The whole idea is that PRACK is a request, like any other. If you don't > treat it differently than any other request, in terms of its ability to > be responded to, you have no problem. > Except it may spawn another PRACK that spawns another PRACK ad infinitum. > > However, if people want to nix the ability to send reliable provisional > responses to PRACK itself, I am willing to discuss. I doubt its useful. > I'd vote for cutting it simply for the reason mentioned above. 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 Wed May 31 04:17:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01619 for ; Wed, 31 May 2000 04:17:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 32D7244346; Wed, 31 May 2000 04:08:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 5835844336 for ; Wed, 31 May 2000 04:08:20 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA29833; Wed, 31 May 2000 09:15:25 +0100 (BST) Message-ID: <3934CA1E.5F3F4B3A@ubiquity.net> Date: Wed, 31 May 2000 09:15:26 +0100 From: James Undery X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Paul E. Jones" , Plong@smithmicro.com, dwillis@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Basic questions References: <000b01bfca41$99f4b760$6701a8c0@plong> <39343C9C.F79563C0@dynamicsoft.com> <019501bfcac3$f8e00e50$0401a8c0@mds.local> <3934A96D.C353848A@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Sorry; I meant at least a single m line (i.e., zero m lines not > allowed). > 4th paragraph of section 6 of RFC 2327 starts "An announcement consists of a session-level section followed by zero or more media-level sections". While this may be useful in a generic case the lack of media means the it is of no use to SIP. I would suggest adding a line along the lines of, SDP used in SIP must contain one or more media-level descriptions, to the bis draft. (Obviously reworded to avoid my awkward prose ;^) ) 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 Wed May 31 04:19:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01633 for ; Wed, 31 May 2000 04:19:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B2CA443BC; Wed, 31 May 2000 04:08:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id C3328443B7 for ; Wed, 31 May 2000 04:08:30 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA29843; Wed, 31 May 2000 09:15:40 +0100 (BST) Message-ID: <3934CA2C.F4538AD5@ubiquity.net> Date: Wed, 31 May 2000 09:15:40 +0100 From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Scott Hoffpauir , sip@lists.bell-labs.com Subject: Re: [SIP] SIP Application Server References: <3933EEB2.893C06AB@ubiquity.net> <39343EDC.2B4005FD@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Neil Deason wrote: > > > > > An applications server can be a proxy, redirect server or user agent. It may > > > be stateful or stateless. It really depends on the applications being > > > provided. I've seen applications servers which are simple redirect servers > > > providing routing functions and more complex ones acting as back-to-back > > > user agents, providing unified messaging. Using SIP allows a softswitch (or > > > other end user device) to pass control to an application server, without > > > having to worry about its architecture or functions. > > > > My apologies if I am confusing the terms here but am I wrong in thinking that a > > SIP Proxy Server qualifies as a Softswitch? I have seen them described as such > > within the Softswitch Consortium. If a SIP Proxy is a Softswitch, isn't this > > approach in danger of reproducing the SSP/SCP model? Why would a Proxy Server > > need to pass an INVITE on to an Application Server for the AS to then > > proxy/redirect it? Couldn't SIP-CGI and CPL provide ways for a Proxy to access > > any service logic required to decide whether to proxy/redirect it directly. A > > Proxy Server augmented with service logic seems to be both a Softswitch and an > > Application Server, which would make defining an interface based on SIP between > > the two interesting. > > This leads back to my original statement. The only difference between a > proxy (I won't get into the softswitch vs. proxy thing, which is purely > a definition issue) and an application server is the complexity of the > programs it executes. In the case you describe, of a proxy implementing > CGI or CPL or JAIN or parlay or whatever apps, it is then an app server. > One could even argue that the proxy function is a type of application > running on an app server. Fact is, it doesn't really matter. > > Samandi Sami later writes: > > I have no access to all the information of the softswitch app. WG, but if I > > have understood the explanation of Scott and what Jonathan answered to my > > first mail, it seems that both have the same point of view. An application > > server is involved in a call as any Proxy/redirect server/UAS and the > > invocation is made as any routing decision via an INVITE in the very > > beginning of the call. That's it. > > Yes. Jonathan I agree that a service logic enhanced Proxy Server is an application server. However, I am not yet convinced this sits in complete harmony with the ISC App WG's intention to separate the call signalling (Proxy/Softswitch) and service control (App Server) and use standard RFC2543 SIP as the interface between them. In the case of the service logic enhanced proxy isn't the interface between vanilla proxy and the service control defined by CPL/SIP-CGI/Servlet API etc not RFC2543 SIP. Regards, 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 May 31 05:20:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01970 for ; Wed, 31 May 2000 05:20:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D4F4244340; Wed, 31 May 2000 05:10:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 3811D44336 for ; Wed, 31 May 2000 05:10:21 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA20273; Wed, 31 May 2000 10:16:11 +0100 (BST) From: "Jo Hornsby" To: "A Srinath" Cc: Subject: RE: [SIP] Retransmissions Date: Wed, 31 May 2000 10:16:11 +0100 Message-ID: <000401bfcae0$dcf43460$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: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Dont we have to send a 481 response to the CANCEL as the earlier > transaction has been completed as a final response has already > been sent. No, it should return 200, since it still has knowledge of the transaction. There was a thread around these issues a few weeks back. Look for the Title "[SIP] CANCEL related questions". > In the same case if the server were a proxy, then does it not forward > the CANCEL downstream too? Yes, the proxy should forward the CANCEL downstream regardless of whether it knows anything about the transaction or not. Again, see the thread mentioned above. - 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 May 31 05:22:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01987 for ; Wed, 31 May 2000 05:22:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A4694435C; Wed, 31 May 2000 05:12:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from habanero.marratech.com (habanero.marratech.com [195.196.47.9]) by lists.bell-labs.com (Postfix) with ESMTP id 5B3A044359 for ; Wed, 31 May 2000 05:12:00 -0400 (EDT) Received: from marratech.com (dhcp016.lulea.marratech.com [195.196.47.16]) by habanero.marratech.com (8.9.3/8.9.3) with ESMTP id LAA10358 for ; Wed, 31 May 2000 11:21:08 +0200 (CEST) Message-ID: <3934D9B6.C12EC896@marratech.com> Date: Wed, 31 May 2000 11:21:58 +0200 From: Petter Tiilikainen X-Mailer: Mozilla 4.7 [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] My master thesis on SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi SIP-people, Just wanted to tell you that my thesis has been published, available at http://epubl.luth.se/1402-1617/2000/137 (scroll down for pdf-file) Not much really of interest there for someone familiar with the basics of SIP or more, however. /Petter _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 06:22:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02497 for ; Wed, 31 May 2000 06:22:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C16A644337; Wed, 31 May 2000 06:13:04 -0400 (EDT) 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 B17C644336 for ; Wed, 31 May 2000 06:13:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02464; Wed, 31 May 2000 06:22:09 -0400 (EDT) Message-Id: <200005311022.GAA02464@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 Date: Wed, 31 May 2000 06:22:08 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-100rel-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --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 : Reliability of Provisional Responses in SIP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-100rel-01.txt Pages : 17 Date : 30-May-00 This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag org.ietf.sip.100rel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-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-100rel-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-100rel-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: <20000530095836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-100rel-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-100rel-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000530095836.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 11:11:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13326 for ; Wed, 31 May 2000 11:11:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 348F844337; Wed, 31 May 2000 11:02:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 5370944336 for ; Wed, 31 May 2000 11:02:27 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id KAA28439 for ; Wed, 31 May 2000 10:13:26 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id KAA25606 for ; Wed, 31 May 2000 10:10:59 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 May 2000 10:10:58 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790DF@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: "'sip@lists.bell-labs.com'" Date: Wed, 31 May 2000 10:10:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] comments on draft-ietf-sip-100rel-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Section 3, Paragraph 1: "Note that a UAS MUST NOT send a response reliably unless there was a Supported header in the request indicating support for this extension." This should be "... unless there was a Supported or Require header in the request indicating support for this extension." ----- Section 3, Paragraph 3: "The UAC can determine that the response is to be transmitted reliably by the presence of the RSeq header." I believe this should read "... by the presence of a Require header containing the option tag 100rel." The use of the Require header in the response is mandated (correctly, in my opinion) by Section 5.2, Paragraph 6 (UAS behavior). This also follows draft-ietf-sip-serverfeatures-02.txt which "allows for the Require header to appear in responses. It is used to indicate what options must be understood by the UAC in order to process the response." In general, I think it's best to explicitly state what extensions/features are being used, rather than having the user agent deduce them from the presence/absence of headers. This also will allow the Rseq header to be reused in other extensions where it might make sense, rather than having to create another extension-specific header. ----- Section 5.1, Paragraph 2: "The rest of this discussion assumes this header has been inserted into a request." This should read "... one of these headers has been inserted ...". The previous paragraph was improved to allow for the UAC to insert either the Supported header or the Require header, and this sentence needs to follow suit. ----- Section 5.1, Paragraph 11: "It is not necessary to include the Supported header listing the option tag 100rel in the PRACK request." I disagree. Given that the UAS may try to send reliable provisional responses to a PRACK (it's mentioned, and seems reasonable for completeness, though I don't see an obvious use of this), I think the UAC ought to say whether it supports or requires the 100rel feature. Yes, the UAS can deduce that the feature is supported by the presence of the PRACK method, but (1) the UAS cannot tell from the existence of the PRACK method whether the UAC *requires* or merely *supports* the 100rel feature, and (2) the PRACK method could never be used in support of any other feature. (2) might not be much of a problem, but I think either a Require or Supported header is needed to address (1). Mandating the header would also make PRACK more consistent with the other methods, all of which mandate either the Require or Supported header. ----- Section 5.2, Paragraph 1: "The UAS may send any provisional response reliably, so long as the initial request contained a Supported header indicating that this feature is understood." This should read "... the initial request contained either a Supported or Require header indicating that this feature is understood." ----- Lastly (and maybe I've missed my chance on this one, since the "open issue" section went away), did we ever come up with an application where the cumulative response mechanism was needed? I thought we had come to consensus to drop it unless there was a demonstrated need (which I haven't seen, though I may have just missed it). The UAC must PRACK a provisional response, which seems to disallow accumulating responses in the hopes of sending one PRACK for the group. Only if a provisional response arrives which is known to be out-of-sequence, and only if it is then cached by the UAC, and only if the previous missing response then arrives, does it seem that the cumulative response mechanism could come into play. The examples section uses "two provisional responses in rapid succession" to address this, but I'm not sure that's sufficient. When the first response arrives, I read section 5.1 (UAC behavior) to require that the UAC construct and send a PRACK; I'm not sure waiting around to see if another response arrives before doing so is reasonable -- it would delay the acknowledgement of the first response in the usually vain hope that another response would quickly arrive. Maybe if the two responses were sent together in a single UDP packet, the cumulative response would be justified? Also, the last paragraph of section 3 and the penultimate paragraph of section 5.2 both recommend that a UAS wait for acknowledgement of a provisional response before sending the next one. Any UAS following this recommended procedure would certainly never need the cumulative response mechanism. I'd take out all the verbiage dealing with the cumulative responses, in the interests of simplicity and clarity. There'd no longer need to be any difference in handling between the first reliable response (which cannot be part of a cumulative group because of the need to agree on the first Rseq) and any further reliable responses. Maybe the space freed up in the examples session could be used to show an example with the Require: 100rel header rather than the Supported: 100rel header. Apologies if I missed some resolution on this cumulative response issue. ----- Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 11:42:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14271 for ; Wed, 31 May 2000 11:42:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D0C34435A; Wed, 31 May 2000 11:32:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 0C27E44336 for ; Wed, 31 May 2000 11:32:40 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA23883; Wed, 31 May 2000 16:39:50 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sip Mail List Date: Wed, 31 May 2000 16:31:41 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00053116384000.31243@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] SipUrl header BNF incorrect in bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi, I think the BNF in the new bis draft concerning SipUrl and headers is wrong: p.18 Section 2 Figure 3 says hname = hnv-unreserved | unreserved | escaped hvalue = hnv-unreserved | unreserved | escaped should this not be: hname = 1*(hnv-unreserved | unreserved | escaped) hvalue = *(hnv-unreserved | unreserved | escaped) small point, but just making sure cheers -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@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 May 31 13:46:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17809 for ; Wed, 31 May 2000 13:46:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B324A44337; Wed, 31 May 2000 13:36:40 -0400 (EDT) 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 8FDDD44336 for ; Wed, 31 May 2000 13:36:37 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Wed, 31 May 2000 12:13:07 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GT17D9; Wed, 31 May 2000 13:12:57 -0400 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LCMSPMNB; Wed, 31 May 2000 13:13:01 -0400 Message-ID: <393548F0.201A5BF9@americasm01.nt.com> Date: Wed, 31 May 2000 13:16:32 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Sip Mail List Subject: Re: [SIP] SipUrl header BNF incorrect in bis References: <00053116384000.31243@gethin> Content-Type: multipart/alternative; boundary="------------A1EC5295974B319891F60598" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------A1EC5295974B319891F60598 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Further to Gethin's point, an earlier discussion on the unreserved characters for paramaters and headers doesn't seem to have been accuarately captured in the May bis. I think the two key requirements for these character sets are 1) they should be subsets of the URL reserved character set (ref RFC 2396/2732), and 2) they should avoid any characters which would cause ambiguities in the SIP grammar. 1. It was discussed that "," should not be included in param-unreserved (and by extension with hnv-unreserved) "because URLs are allowed in certain headers and allowing commas in SIP URLs will make parsing those headers sometime impossible.". I thought this point was accepted, but maybe I missed something. 2. RFC 2732 adds "[" and "]" to the URL reserved set to support IPv6 address syntax. As a consequence, I think these should also be added to param-unreserved and hnv-unreserved, since I don't think they cause any ambiguity issues. Rick Workman Nortel Networks Gethin Liddell wrote: > Hi, > > I think the BNF in the new bis draft concerning SipUrl and headers is wrong: > > p.18 Section 2 Figure 3 says > > hname = hnv-unreserved | unreserved | escaped > hvalue = hnv-unreserved | unreserved | escaped > > should this not be: > > hname = 1*(hnv-unreserved | unreserved | escaped) > hvalue = *(hnv-unreserved | unreserved | escaped) > > small point, but just making sure > > cheers > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------A1EC5295974B319891F60598 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Further to Gethin's point, an earlier discussion on the unreserved characters for paramaters and headers doesn't seem to have been accuarately captured in the May bis. I think the two key requirements for these character sets are 1) they should be subsets of the URL reserved character set (ref RFC 2396/2732), and 2) they should avoid any characters which would cause ambiguities in the SIP grammar.

1. It was discussed that "," should not be included in param-unreserved (and by extension with hnv-unreserved) "because URLs are allowed in certain headers and allowing commas in SIP URLs will make parsing those headers sometime impossible.". I thought this point was accepted, but maybe I missed something.

2. RFC 2732 adds "[" and "]" to the URL reserved set to support IPv6 address syntax. As a consequence, I think these should also be added to param-unreserved and hnv-unreserved, since I don't think they cause any ambiguity issues.
 

Rick Workman
Nortel Networks
 

Gethin Liddell wrote:

Hi,

I think the BNF in the new bis draft concerning SipUrl and headers is wrong:

p.18 Section 2 Figure 3 says

hname = hnv-unreserved | unreserved | escaped
hvalue = hnv-unreserved | unreserved | escaped

should this not be:

hname = 1*(hnv-unreserved | unreserved | escaped)
hvalue = *(hnv-unreserved | unreserved | escaped)

small point, but just making sure

cheers

--
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:gethin@ubiquity.net

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

--------------A1EC5295974B319891F60598-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 14:55:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20286 for ; Wed, 31 May 2000 14:55:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A1B744346; Wed, 31 May 2000 14:46:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from crash.netspeak.com (unknown [208.143.140.6]) by lists.bell-labs.com (Postfix) with ESMTP id 62CE944336 for ; Wed, 31 May 2000 14:46:24 -0400 (EDT) Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 14:54:30 -0400 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A60B3ED8@crash.engineering.netspeak.com> From: Linden deCarmo To: sip@lists.bell-labs.com Date: Wed, 31 May 2000 14:54:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Suspend a session?? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Right now, SIP smoothly handles one party putting another party on hold via a re-INVITE with modified SDP. However, we have a scenario where the session needs to be suspended (not just placed on hold), and I'm not sure how this can be done without using proprietary headers. Here are ther details. If party A calls party B , party B should be able to hang up without immediately terminating the session. If party B picks up the phone within some prescribed time window, the session continues. However, if they don't pick it up within the time window, the session terminates (via a BYE). We're looking for a mechanism for party B to communicate with either party A or a proxy server, to inform the distant party that the session has been suspended, and not just placed on hold. The primary motivator for this notification is billing. Without notification of suspension, its impossible to determine when to safely stop billing. Thanks. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 16:30:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24068 for ; Wed, 31 May 2000 16:30:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6809044356; Wed, 31 May 2000 16:20:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by lists.bell-labs.com (Postfix) with ESMTP id 8999744351 for ; Wed, 31 May 2000 16:20:36 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id PAA03777 for ; Wed, 31 May 2000 15:31:44 -0500 (CDT) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id PAA02482 for ; Wed, 31 May 2000 15:28:29 -0500 (CDT) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 May 2000 15:28:29 -0500 Message-ID: <4D45BA2A58A7D3119E050008C7E69E290790E1@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: "'sip@lists.bell-labs.com'" Subject: FW: [SIP] wg last call on reliable provisional responses Date: Wed, 31 May 2000 15:28:25 -0500 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com James Undery writes: I think what is being hinted at albeit subtlety is, is the transaction ever going to end? (The Halting Problem.) Although I can't think of a case off hand where you'd want to provisionally respond to a PRACK, specifically allowing it is just asking for trouble between legitimate implementations. [...] Except it may spawn another PRACK that spawns another PRACK ad infinitum. I was going to write in support of reliable provisional responses for PRACK, but I think this sways me over to the opposition. One could get one's self into a fair amount of trouble receiving a PRACK and sending a reliable provisional response that results in receiving another PRACK, etc. This would also address my previous comment about mandating Require: 100rel or Supported: 100rel in a PRACK message, rather than relying on the presence of PRACK to imply support. The UAC could of course include the Require or Supported header if it chose, but it'd be moot because the UAS would not be allowed to send a reliable provisional response. The UAS would therefore not be allowed to put the Require: 100rel in a provisional response to a PRACK. Tim Schroeder tschroeder@tri.sbc.com SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX 78759 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 17:07:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24989 for ; Wed, 31 May 2000 17:07:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 315E944351; Wed, 31 May 2000 16:57:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from notes.relteccorp.com (unknown [208.43.60.82]) by lists.bell-labs.com (Postfix) with SMTP id 88AF444337 for ; Wed, 31 May 2000 16:57:52 -0400 (EDT) Received: by notes.relteccorp.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568F0.0073E504 ; Wed, 31 May 2000 17:05:52 -0400 X-Lotus-FromDomain: MCMAIN@MCEXT From: david.k.brown@marconi.com To: sip@lists.bell-labs.com Message-ID: <852568F0.0073E2E6.00@notes.relteccorp.com> Date: Wed, 31 May 2000 16:02:33 -0500 Subject: RE: [SIP] Basic questions 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com "Dave Oran" on 05/30/2000 01:30:31 PM To: "charles Agboh" , "Dean Willis" , sip@lists.bell-labs.com cc: "Jonathan Rosenberg" (bcc: David K Brown/MAIN/MC1) Subject: RE: [SIP] Basic questions > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of charles Agboh > > Sent: Tuesday, May 30, 2000 9:06 AM > > To: Dean Willis; sip@lists.bell-labs.com > > Cc: Jonathan Rosenberg > > Subject: Re: [SIP] Basic questions > > > > > > > > Can somebody please answer the following question? " > > > > How can you have a "session" of any kind with only one participant? > > > > charles > > What is the sound of one hand clapping? > > SIP can set up Zen sessions. It's completely general. It may be general enough to allow these sessions but are they useful (some multi-cast situations have been identified but those looked like transitional situations). I'm looking at this from the standpoint of possible services, not strictly protocol rules. Would single particiapant sessions possibly be of use in the following types of service conditions: transition (adding, removing, or locating participants), residue of failed or disrupted sessions (is this possible for even a few moments?), pending sessions, meet-me or third party controlled type conference sessions (which might even reasonably conceptually have NO participants at some stage). These possible single participant situations are all transitions in a larger service, does anyone anticipate a single participant only service? Dave Brown Marconi Comms _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed May 31 19:05:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26797 for ; Wed, 31 May 2000 19:05:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D240844351; Wed, 31 May 2000 18:55:47 -0400 (EDT) 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 0858544337 for ; Wed, 31 May 2000 18:55:45 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id FAA08972; Thu, 1 Jun 2000 05:06:59 -0500 Message-Id: <200006011006.FAA08972@kevlar.softarmor.com> Date: Wed, 31 May 2000 18:06:59 -0500 From: Dean Willis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Linden deCarmo Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Suspend a session?? References: <6C5713970B1FD411ACBE00AA00DCD9A60B3ED8@crash.engineering.netspeak.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Have you considered building an auto-hold on switch-hook with a timer that initaies a BYE into your UA? My first thought is that the suggested behavior is a UA problem, not a proxy problem. Unless it is a flaw in the billing model . . . B calls A. B places receiver on-hook. B sends reINVITE-to-HOLD to A. B starts timer. Timer expires. B sends BYE to A. The only issue I see here is that B might vanish during the hold-period and fail to send the BYE. This is a risk with call-hold in general, and I believe there has been a proposal to use a configurable hold-timer in end devices to recover from it. -- Dean Linden deCarmo wrote: > > Right now, SIP smoothly handles one party putting another party on hold via > a re-INVITE with modified SDP. However, we have a scenario where the > session needs to be suspended (not just placed on hold), and I'm not sure > how this can be done without using proprietary headers. > > Here are ther details. If party A calls party B , party B should be able to > hang up without immediately terminating the session. If party B picks up > the phone within some prescribed time window, the session continues. > However, if they don't pick it up within the time window, the session > terminates (via a BYE). > > We're looking for a mechanism for party B to communicate with either party A > or a proxy server, to inform the distant party that the session has been > suspended, and not just placed on hold. The primary motivator for this > notification is billing. Without notification of suspension, its impossible > to determine when to safely stop billing. > > Thanks. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > _______________________________________________ > 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 May 31 21:46:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00212 for ; Wed, 31 May 2000 21:46:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7DD94435E; Wed, 31 May 2000 21:37:07 -0400 (EDT) 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 1740D44337 for ; Wed, 31 May 2000 21:37:05 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FVG00L01CX84U@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 1 Jun 2000 01:46:20 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FVG00KFPCX71E@firewall.mcit.com>; Thu, 01 Jun 2000 01:46:20 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) id <0FVG00501CX7SX@pmismtp02.wcomnet.com>; Thu, 01 Jun 2000 01:46:19 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0FVG00501CX7SV@pmismtp02.wcomnet.com>; Thu, 01 Jun 2000 01:46:19 +0000 (GMT) Received: from C25776A ([166.44.153.175]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0FVG0015TCSQI7@pmismtp02.wcomnet.com>; Thu, 01 Jun 2000 01:46:11 +0000 (GMT) Date: Wed, 31 May 2000 20:46:07 -0500 From: Henry Sinnreich Subject: RE: [SIP] Suspend a session?? In-reply-to: <200006011006.FAA08972@kevlar.softarmor.com> To: Dean Willis , Linden deCarmo Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit If it was my decision, I would bill only for the QoS minutes for this call. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dean Willis >Sent: Wednesday, May 31, 2000 6:07 PM >To: Linden deCarmo >Cc: sip@lists.bell-labs.com >Subject: Re: [SIP] Suspend a session?? > > > >Have you considered building an auto-hold on >switch-hook with a timer >that initaies a BYE into your UA? My first thought is >that the suggested >behavior is a UA problem, not a proxy problem. Unless >it is a flaw in >the billing model . . . > >B calls A. >B places receiver on-hook. >B sends reINVITE-to-HOLD to A. >B starts timer. >Timer expires. >B sends BYE to A. > >The only issue I see here is that B might vanish >during the hold-period >and fail to send the BYE. This is a risk with >call-hold in general, and >I believe there has been a proposal to use a >configurable hold-timer in >end devices to recover from it. > >-- >Dean > >Linden deCarmo wrote: >> >> Right now, SIP smoothly handles one party putting >another party on hold via >> a re-INVITE with modified SDP. However, we have a >scenario where the >> session needs to be suspended (not just placed on >hold), and I'm not sure >> how this can be done without using proprietary headers. >> >> Here are ther details. If party A calls party B , >party B should be able to >> hang up without immediately terminating the session. > If party B picks up >> the phone within some prescribed time window, the >session continues. >> However, if they don't pick it up within the time >window, the session >> terminates (via a BYE). >> >> We're looking for a mechanism for party B to >communicate with either party A >> or a proxy server, to inform the distant party that >the session has been >> suspended, and not just placed on hold. The primary >motivator for this >> notification is billing. Without notification of >suspension, its impossible >> to determine when to safely stop billing. >> >> Thanks. >> >> Linden deCarmo >> Netspeak Corporation >> 902 Clint Moore Road >> Suite 104 >> Boca Raton, FL 33487 >> >> _______________________________________________ >> 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