From sip-admin@ietf.org Mon Oct 1 11:05:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19849 for ; Mon, 1 Oct 2001 11:05:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28745; Mon, 1 Oct 2001 10:16:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28717 for ; Mon, 1 Oct 2001 10:16:04 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18261 for ; Mon, 1 Oct 2001 10:16:00 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f91EFp726549 for ; Mon, 1 Oct 2001 16:16:02 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f91EFmb26957 for ; Mon, 1 Oct 2001 17:15:48 +0300 (EET DST) Message-ID: <3BB87A92.2FF5AAC1@lmf.ericsson.se> Date: Mon, 01 Oct 2001 17:15:46 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Forking, early media and RTCP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A couple of weeks ago, during the media-line-matching discussion, it was mentioned that the m= lines in the request and the response MUST match. It was also said that it is not possible, if two codecs are used, to use a single port for both codecs on one client, and two separate ports for the codecs on the other nodes, since that will mess up the RTCP signalling. However, I think that this will happen also when an INVITE forks, and more than one UAS wants to send and/or receive early media. In this case the UAC is going to use a single port for multiple streams, but communicate with multiple (the only difference from the m= line issue is that the remote ports now probably will be on separate IP addresses). What will happen to the RTCP signalling now? Using the manyfolks extension I think this is not a problem, because whenever we receive a 18x for a new leg we may reserve a new media port for that leg and send it in the "final SDP" in the PRACK. In basic SIP, however, that is not possible. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 1 14:41:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26501 for ; Mon, 1 Oct 2001 14:41:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06858; Mon, 1 Oct 2001 13:46:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06827 for ; Mon, 1 Oct 2001 13:46:29 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24942 for ; Mon, 1 Oct 2001 13:46:23 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f91HjMS16741 for ; Mon, 1 Oct 2001 13:45:22 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 1 Oct 2001 13:45:48 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 13:45:47 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514FBEB@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'sip@ietf.org'" Cc: "'klingle@cisco.com'" , "'jmaeng@ipdialog.com'" , "'jfm@clarent.com'" , "'drwalker@ss8.com'" Date: Mon, 1 Oct 2001 13:45:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14AA0.DE61AAD0" X-Orig: Subject: [Sip] Review of draft-ietf-sip-mib-03.txt Part 1 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C14AA0.DE61AAD0 Content-Type: text/plain; charset="iso-8859-1" Time I got this out, just to get discussion going. The rest will follow soon. Substantive Issues ================== Section 5.2: ----------- sipServiceOperStatus: since the status values are supposed to be mapped to applOperStatus, why not just use the values of the latter, adding values above them where they are lacking? Currently: applOperStatus: up(1), down(2), halted(3), congested(4), restarting(5), quiescing(6) sipServiceOperStatus: up(1), down(2), testing(3), unknown(4), halted(5), restarting(6) sipServiceAdminStatus: - What value would be read when the entity is operating normally? - The descriptions of the values should indicate what operational status transitions they bring about. sipServiceStartTime, sipServiceLastChange DESCRIPTION: sysUpTime is not defined -- should there be a reference? sipMaxSessions: is "session" equivalent to call-leg in a UA, transaction in any other entity? Should the description say so? What value is put in for a stateless proxy? sipInviteTimeOut: appears to apply only to UAs, hence may belong in the SIP-UA-MIB. We need a corresponding entry for default registration timeouts, at both the UAC and the Registrar ends. General comment: should it be possible to retrieve on a read-only basis the capabilities of the SIP entity as expressed in the Allow, Supported, and Accept headers respectively? Supported has its equivalent in the sipFtrSupportedTable, but the other items also need definition. Might want a read-write object corresponding to Accept-Language. sipFtrSupported: should this have provision for feature version? Or will new versions mean new option tags? sipCommonCfgTimerxxx: Do we really need timer settings per method? The RFC 2543bis description of behaviour distinguishes between two transmission timing situations: regular requests (not INVITE or ACK) vs. INVITE. For the former we actually need two timer settings: for the initial value T1 and the upper bound T2. For INVITE we need just T1, which could differ from the T1 for other methods. We also, absolutely, need the application-level timer defined as sipCfgTimerProv. sipCfgRetryxxx: are these meant to control the number of times a transaction of the given type will be reinitiated when the previous attempt has met with 4xx or 5xx failure or has died due to reaching the retransmission limit? This would be like the automatic retries done by a FAX machine, but I suspect it wouldn't be generally useful -- better to rely on user reinitiation except perhaps for REGISTER requests. Or do they set the maximum number of retransmissions? The latter control is not needed: the maximum number of retransmissions is set unequivocally by the RFC. sipCfgRetryNonFinalResponse: clearly meant for retransmissions, and useless unless the 100rel feature is being used. Nits and editorial ================== Need an IANA Considerations section. General: capitalize MUST, SHOULD, SHOULD NOT, MAY. Section 4: ----------- first para (top of p. 4): slight redundancy, slightly garbled. I suggest that the fourth and fifth sentences be replaced by: "SIP-COMMON-MIB contains common objects used in all the SIP entities. SIP-SERVER-MIB contains objects for Registrars, Proxies, and Redirect servers, and SIP-UA-MIB contains objects for User Agents." Next para: change "Each MIB Module contain following.." to "The MIB Modules contain the following.." The final para, after the list of MIB contents, might more clearly read: "To conform with this specification, an SNMP agent MUST implement SIP-MIB-SMI, SIP-TC, plus one instance of SIP-COMMON-MIB and one instance of the SIP entity-type-specific MIB (SIP-SERVER-MIB or SIP-UA-MIB) as applicable for each instance of a SIP entity being managed. Section 4.2 describes handling of multiple instances in detail." Section 4.2: ----------- First para: I suggest this sentence be inserted after the first sentence, to capture your thought: " ...SNMP agent. This can happen because the same system supports multiple SIP entity types." Second para is really unclear and somewhat redundant with section 4. I suggest it be rewritten as follows (if I have understood correctly what you meant to say): "In either case, the operator may choose to represent the system as an aggregate entity, requiring one copy of the SIP-COMMON-MIB and a copy of the SIP-SERVER-MIB and/or the SIP-UA-MIB as required. Alternatively, each SIP entity instance may be associated with its own copy of the SIP-COMMON-MIB and its own copy of the SIP entity-type-specific MIB. This latter mode of operation provides the requirement for supporting multiple instances of a particular MIB module in one system." I suggest you add this sentence at the end of the third para to make clear what applIndex is being used for: "The applIndex is then used to distinguish SIP entity instances in the SIP-COMMON-MIB and the SIP entity-type-specific MIBs." Description of how to populate applName, final bullet beginning "for a SIP entity acting in...": suggest it begin as follows: " o For any combination of Proxy, Registrar, or Redirect Server being managed as a single aggregate entity, the applName ... " Next para, beginning "Additionally, the following objects ..." can be rewritten to reduce redundancy and at the same time eliminate the note following the specific object mappings if it is written as follows: "The SNMP agent MAY support any combination of the other attributes in applTable. If the following objects are supported, the object values SHOULD ..." In the bullets for applUptime and applLastChange, SIP-COMMON should be SIP-COMMON-MIB. Example 1: suggest the first sentence be modified slightly to read: "The tables below illustrate how a system acting as both Proxy and Registrar server might be configured to maintain separate SIP-COMMON-MIB instances." In the rest of the example, change "would be populated" and "is populated" to "might be populated". Example 2: modify the first sentence to read: This example illustrates how to represent a system acting as both Proxy and Registrar server, where the two entities share a single instance of SIP-COMMON-MIB. Section 5.2: ----------- sipCommonMIB DESCRIPTION: don't repeat the definitions of the different entities -- just refer back to the 2543 definitions section. sipCommonCfgEntry DESCRIPTION: insert the word "instance" after the word "entity" at the beginning of the second line. (The word "those" is not needed in the first line.) sipOrganization DESCRIPTION: suggest the description (which currently quotes the definition of the Organization header) be modified to read: "This object contains the organization name which the SIP entity inserts into Organization headers which it adds to SIP messages processed by it. If the string is empty no Organization header is to be generated." sipPortStatus: description should say whether elements of the row can be modified when RowStatus is Active. sipFtrSupported: the description should indicate whether the complete path (i.e. org.ietf.sip.xxx) has to be entered for IETF-standardized features. sipCfgInitialTimerInvite: description should specify that this is the initial value T1 for the retransmission timer. References: ---------- [18]: misprinted name, quotation marks. Should be: N. Freed, S. Kille, "Network Services Monitoring MIB", ... Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C14AA0.DE61AAD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-sip-mib-03.txt Part 1

Time I got this out, just to get discussion = going.  The rest will follow soon.

Substantive Issues
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Section 5.2:
-----------
sipServiceOperStatus: since the status values are = supposed to be mapped to applOperStatus, why not just use the values of = the latter, adding values above them where they are lacking?

Currently:
    applOperStatus: up(1), down(2), = halted(3), congested(4), restarting(5), quiescing(6)
    sipServiceOperStatus: up(1), = down(2), testing(3), unknown(4), halted(5), restarting(6)

sipServiceAdminStatus:
- What value would be read when the entity is = operating normally?
- The descriptions of the values should indicate = what operational status transitions they bring about.

sipServiceStartTime, sipServiceLastChange = DESCRIPTION: sysUpTime is not defined -- should there be a = reference?

sipMaxSessions: is "session" equivalent to = call-leg in a UA, transaction in any other entity?  Should the = description say so?  What value is put in for a stateless = proxy?

sipInviteTimeOut: appears to apply only to UAs, hence = may belong in the SIP-UA-MIB.  We need a corresponding entry for = default registration timeouts, at both the UAC and the Registrar = ends.

General comment: should it be possible to retrieve on = a read-only basis the capabilities of  the SIP entity as expressed = in the Allow, Supported, and Accept headers respectively?  = Supported has its equivalent in the sipFtrSupportedTable, but the other = items also need definition.

Might want a read-write object corresponding to = Accept-Language.

sipFtrSupported: should this have provision for = feature version?  Or will new versions mean new option = tags?

sipCommonCfgTimerxxx: Do we really need timer = settings per method?  The RFC 2543bis description of behaviour = distinguishes between two transmission timing situations: regular = requests (not INVITE or ACK) vs. INVITE.  For the former we = actually need two timer settings: for the initial value T1 and the = upper bound T2.  For INVITE we need just T1, which could differ = from the T1 for other methods.  We also, absolutely, need the = application-level timer defined as sipCfgTimerProv.

sipCfgRetryxxx: are these meant to control the number = of times a transaction of the given type will be reinitiated when the = previous attempt has met with 4xx or 5xx failure or has died due to = reaching the retransmission limit?  This would be like the = automatic retries done by a FAX machine, but I suspect it wouldn't be = generally useful -- better to rely on user reinitiation except perhaps = for REGISTER requests.  Or do they set the maximum number of = retransmissions?  The latter control is not needed: the maximum = number of retransmissions is set unequivocally by the RFC.

sipCfgRetryNonFinalResponse: clearly meant for = retransmissions, and useless unless the 100rel feature is being = used.
 
Nits and editorial
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Need an IANA Considerations section.

General: capitalize MUST, SHOULD, SHOULD NOT, = MAY.

Section 4:
-----------
first para (top of p. 4): slight redundancy, = slightly garbled.  I suggest that the fourth and fifth sentences = be replaced by:

"SIP-COMMON-MIB contains common objects used in = all the SIP entities.  SIP-SERVER-MIB contains objects for = Registrars, Proxies, and Redirect servers, and SIP-UA-MIB contains = objects for User Agents."

Next para: change "Each MIB Module contain = following.." to "The MIB Modules contain the = following.."

The final para, after the list of MIB contents, might = more clearly read:

"To conform with this specification, an SNMP = agent MUST implement SIP-MIB-SMI, SIP-TC, plus one instance of = SIP-COMMON-MIB and one instance of the SIP entity-type-specific MIB = (SIP-SERVER-MIB or SIP-UA-MIB) as applicable for each instance of a SIP = entity being managed.  Section 4.2 describes handling of multiple = instances in detail."

Section 4.2:
-----------
First para: I suggest this sentence be inserted = after the first sentence, to capture your thought:
" ...SNMP agent. This can happen because the = same system supports multiple SIP entity types."

Second para is really unclear and somewhat redundant = with section 4.  I suggest it be rewritten as follows (if I have = understood correctly what you meant to say):

"In either case, the operator may choose to = represent the system as an aggregate entity, requiring one copy of the = SIP-COMMON-MIB and a copy of the SIP-SERVER-MIB and/or the SIP-UA-MIB = as required.  Alternatively, each SIP entity instance may be = associated with its own copy of the SIP-COMMON-MIB and its own copy of = the SIP entity-type-specific MIB.  This latter mode of operation = provides the requirement for supporting multiple instances of a = particular MIB module in one system."

I suggest you add this sentence at the end of the = third para to make clear what applIndex is being used for:
"The applIndex is then used to distinguish SIP = entity instances in the SIP-COMMON-MIB and the SIP entity-type-specific = MIBs."

Description of how to populate applName, final bullet = beginning "for a SIP entity acting in...": suggest it begin = as follows:

" o  For any combination of Proxy, = Registrar, or Redirect Server being managed as a single aggregate = entity, the applName ... "

Next para, beginning "Additionally, the = following objects ..." can be rewritten to reduce redundancy and = at the same time eliminate the note following the specific object = mappings if it is written as follows:

"The SNMP agent MAY support any combination of = the other attributes in applTable.  If the following objects are = supported, the object values SHOULD ..."

In the bullets for applUptime and applLastChange, = SIP-COMMON should be SIP-COMMON-MIB.

Example 1: suggest the first sentence be modified = slightly to read:
"The tables below illustrate how a system = acting as both Proxy and Registrar server might be configured to = maintain separate SIP-COMMON-MIB instances."

In the rest of the example, change "would be = populated" and "is populated" to "might be populated= ".

Example 2: modify the first sentence to read:
This example illustrates how to represent a system = acting as both Proxy and Registrar server, where the two entities share = a single instance of SIP-COMMON-MIB.

Section 5.2:
-----------
sipCommonMIB DESCRIPTION: don't repeat the = definitions of the different entities -- just refer back to the 2543 = definitions section.

sipCommonCfgEntry DESCRIPTION: insert the word = "instance" after the word "entity" at the beginning = of the second line.  (The word "those" is not needed in = the first line.)

sipOrganization DESCRIPTION: suggest the description = (which currently quotes the definition of the Organization header) be = modified to read:

"This object contains the organization name = which the SIP entity inserts into Organization headers which it adds to = SIP messages processed by it.  If the string is empty no = Organization header is to be generated."

sipPortStatus: description should say whether = elements of the row can be modified when RowStatus is Active.

sipFtrSupported: the description should indicate = whether the complete path (i.e. org.ietf.sip.xxx) has to be entered for = IETF-standardized features.

sipCfgInitialTimerInvite: description should specify = that this is the initial value T1 for the retransmission timer.

References:
----------
[18]: misprinted name, quotation marks.  Should = be:
   N. Freed, S. Kille, "Network = Services Monitoring MIB", ...

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C14AA0.DE61AAD0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 1 18:15:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02984 for ; Mon, 1 Oct 2001 18:15:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13262; Mon, 1 Oct 2001 17:44:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12662 for ; Mon, 1 Oct 2001 17:26:16 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01645 for ; Mon, 1 Oct 2001 17:26:12 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 14:24:36 -0700 Message-ID: From: "Clay, Martha" Date: Mon, 1 Oct 2001 14:24:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Nuera to host 9th SIPit event Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello! Nuera Communications, Inc. is hosting the 9th SIPit event in San Diego, CA from December 2 - 7, 2001, and we would like to invite your participation. Please visit our website at https://www.nuera.com/sipit/index.cfm for event information. Registration is now open and will be available on-line until October 20; payment must be received by November 10, 2001. If you have any questions after reviewing the information, please email or call me directly. We look forward to seeing you there! Sincerely, Martha H. Clay Director of Marketing Communications Nuera Communications, Inc. 858.625.2400 858.625.2422 fax Note: Although I do not anticipate the need to send more than 1-2 additional update emails, I will gladly remove you from this email list at your request. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 2 16:07:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27849 for ; Tue, 2 Oct 2001 16:07:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24321; Tue, 2 Oct 2001 15:42:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24269 for ; Tue, 2 Oct 2001 15:42:05 -0400 (EDT) Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26956 for ; Tue, 2 Oct 2001 15:42:00 -0400 (EDT) Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1]) by mail.net2phone.com (8.11.5/8.11.5) with ESMTP id f92JffP16618; Tue, 2 Oct 2001 15:41:41 -0400 (EDT) Received: by mailsvr with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 15:41:53 -0400 Message-ID: <6F46FABB90ABD411BD690002B3152FB946701A@lkwmail01> From: Romel Khan To: byerly@cisco.com, sip@ietf.org Subject: RE: [Sip] What is the mapping of ANI II digits to rpi-np? Date: Tue, 2 Oct 2001 15:39:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org How about do something like: From: where oli = originating line information = ani-ii This encloses the II information within telephone URL consistent with RFC2806 and makes it independent of SIP. -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Saturday, September 29, 2001 8:05 PM To: byerly@cisco.com; sip@ietf.org Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? To all, In a message dated 9/28/01 5:11:08 PM Eastern Daylight Time, byerly@cisco.com writes: << Hi guys, I had initially sent out a question on this issue and received no responses; so I'm trying again... :^) I'm trying to understand the appropriate translation of ANI II digits to their SIP equivalent. However, when I try to match the currently defined ANI II digits from http://www.nanpa.com/number_resource_info/ani_ii_assignments.html against the keywords defined in Appendix A of draft-ietf-sip-privacy-02.txt, it appears to be a sparse, non-invertible mapping. So, I have a few questions: 1) Is there a more recent version of this syntax? 2) Could someone define a less sparse, invertible mapping as a best current practice? 3) Should we instead just define a new tag such as, ";ani-ii=number" ? 4) Other ideas? >> <; Tue, 2 Oct 2001 17:58:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28439; Tue, 2 Oct 2001 17:40:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28408 for ; Tue, 2 Oct 2001 17:40:01 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00447 for ; Tue, 2 Oct 2001 17:39:56 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f92LduE06629; Tue, 2 Oct 2001 17:39:56 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Christer Holmberg'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Tue, 2 Oct 2001 17:40:06 -0400 Message-ID: <000b01c14b8a$ce1cf9a0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BB03883.42578FBE@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > So, if the UAS receives a re-INVITE w/o SDP, > and then also receives an > ACK w/o SDP, what does it do? For the initial > INVITE, it probably releases the call, > because it's a protocol error. Does the UAS do the > same here, or should it assume that the UAC SDP > has not changed? Assuming a 2xx response was sent from UAS, it is a protocol error per rfc2543bis-04. The resulting action is undefined. Once the offer/answer SDP usage is split into a separate draft, I assume that the resulting action will remain undefined to avoid constantly defining how devices should handle each and every protocol violation. With that said, I assume most devices will release the call. Others might assume the SDP hasn't changed. Others will trigger a reinvite with SDP to obtain the protocol violators SDP. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 2 20:28:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04461 for ; Tue, 2 Oct 2001 20:28:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02190; Tue, 2 Oct 2001 20:07:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02160 for ; Tue, 2 Oct 2001 20:07:00 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04092 for ; Tue, 2 Oct 2001 20:06:56 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9304M729492; Tue, 2 Oct 2001 17:04:22 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f9306PU27137; Tue, 2 Oct 2001 17:06:25 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id RAA16053; Tue, 2 Oct 2001 17:06:23 -0700 (PDT) Message-ID: <3BBA5704.D61242CB@cisco.com> Date: Tue, 02 Oct 2001 20:08:37 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: byerly@cisco.com, sip@ietf.org Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? References: <139.25bf41d.28e7bbb8@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mpierce1@aol.com wrote: > To all, > > In a message dated 9/28/01 5:11:08 PM Eastern Daylight Time, byerly@cisco.com > writes: > > << Hi guys, > > I had initially sent out a question on this issue and received no > responses; so I'm trying again... :^) > > I'm trying to understand the appropriate translation of ANI II digits to > their SIP equivalent. However, when > I try to match the currently defined ANI II digits from > http://www.nanpa.com/number_resource_info/ani_ii_assignments.html > against the keywords defined in > Appendix A of draft-ietf-sip-privacy-02.txt, it appears to be a sparse, > non-invertible mapping. > > So, I have a few questions: > 1) Is there a more recent version of this syntax? > 2) Could someone define a less sparse, invertible mapping as a best > current practice? > 3) Should we instead just define a new tag such as, ";ani-ii=number" ? > 4) Other ideas? >> > > < It seems best to use your suggestion 3 - simply define a tag for > "ani-ii=number" and use the currently defined numbers, not some newly > invented list of keywords that have unknown meanings. Let's not reinvent the > wheel! Yes and no. As Alan indicated, we already have SIP-T to handle the "good old wheel case" and we shouldn't just blindly copy existing PSTN parameters to SIP headers. Some issues to consider here: - do we really want to get into to coin control signalling ? - is there a need for indicating toll free services via ANI II when we have tel-URL ? - perhaps most importantly, what kind of SIP-relevant information above and beyond ANI II would we actually like to convey (generalize it) ? -- Flemming > > > Mike Pierce > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 2 20:30:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04552 for ; Tue, 2 Oct 2001 20:30:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02295; Tue, 2 Oct 2001 20:09:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02268 for ; Tue, 2 Oct 2001 20:09:17 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04113 for ; Tue, 2 Oct 2001 20:09:13 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.11.6/8.9.1) with ESMTP id f9308GG06119; Tue, 2 Oct 2001 17:08:16 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f9308EA28347; Tue, 2 Oct 2001 17:08:14 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id RAA16881; Tue, 2 Oct 2001 17:08:12 -0700 (PDT) Message-ID: <3BBA5772.2654C03B@cisco.com> Date: Tue, 02 Oct 2001 20:10:26 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Romel Khan CC: byerly@cisco.com, sip@ietf.org Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? References: <6F46FABB90ABD411BD690002B3152FB946701A@lkwmail01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Romel Khan wrote: > How about do something like: > From: > where oli = originating line information = ani-ii > Who adds the ANI II ? How do you know you can trust it ? -- Flemming > > This encloses the II information within telephone URL consistent with > RFC2806 and makes it independent of SIP. > > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Saturday, September 29, 2001 8:05 PM > To: byerly@cisco.com; sip@ietf.org > Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? > > To all, > > In a message dated 9/28/01 5:11:08 PM Eastern Daylight Time, > byerly@cisco.com > writes: > > << Hi guys, > > I had initially sent out a question on this issue and received no > responses; so I'm trying again... :^) > > I'm trying to understand the appropriate translation of ANI II digits to > their SIP equivalent. However, when > I try to match the currently defined ANI II digits from > http://www.nanpa.com/number_resource_info/ani_ii_assignments.html > against the keywords defined in > Appendix A of draft-ietf-sip-privacy-02.txt, it appears to be a sparse, > non-invertible mapping. > > So, I have a few questions: > 1) Is there a more recent version of this syntax? > 2) Could someone define a less sparse, invertible mapping as a best > current practice? > 3) Should we instead just define a new tag such as, ";ani-ii=number" ? > 4) Other ideas? >> > > < It seems best to use your suggestion 3 - simply define a tag for > "ani-ii=number" and use the currently defined numbers, not some newly > invented list of keywords that have unknown meanings. Let's not reinvent the > > wheel! > > Mike Pierce > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 2 23:55:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12400 for ; Tue, 2 Oct 2001 23:55:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06357; Tue, 2 Oct 2001 22:58:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06328 for ; Tue, 2 Oct 2001 22:58:23 -0400 (EDT) Received: from imo-d08.mx.aol.com (imo-d08.mx.aol.com [205.188.157.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10831 for ; Tue, 2 Oct 2001 22:58:18 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d08.mx.aol.com (mail_out_v31_r1.7.) id p.99.1b911548 (3934); Tue, 2 Oct 2001 22:57:17 -0400 (EDT) Message-ID: <99.1b911548.28ebd88c@aol.com> Date: Tue, 2 Oct 2001 22:57:16 EDT Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? To: rkhan@net2phone.com, sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 112 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 10/2/01 4:00:17 PM Eastern Daylight Time, rkhan@net2phone.com writes: << How about do something like: From: where oli = originating line information = ani-ii This encloses the II information within telephone URL consistent with RFC2806 and makes it independent of SIP. >> It doesn't make any difference to me how it is coded (nor do I completely understand the coding being used). My only point is that SIP should use the set of numeric values already defined in the telephone industry (through a multi-decade evolutionary process), not invent a new list of values. If there are additional values needed to support the SIP application for the type of "telephones" that will originate calls, then a simple request to the NANPA would likely get new codes asigned. It is their job, just like IANA assigns codes in the Internet. If there are values that are not needed, like "coin control", then they simply won't be used in SIP. However, why wouldn't "coin control" be possible. Won't someone want to build coin phones that run on SIP? Seems like a good business to me. Mike Pierce _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 01:52:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17792 for ; Wed, 3 Oct 2001 01:52:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17345; Wed, 3 Oct 2001 01:32:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17316 for ; Wed, 3 Oct 2001 01:32:34 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16222 for ; Wed, 3 Oct 2001 01:32:31 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f935WJL10401; Wed, 3 Oct 2001 07:32:20 +0200 (MEST) Received: from lmf.ericsson.se (lmf03754pc.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f935WJN14277; Wed, 3 Oct 2001 08:32:19 +0300 (EET DST) Message-ID: <3BBAA2E1.F8331F5F@lmf.ericsson.se> Date: Wed, 03 Oct 2001 08:32:17 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <000b01c14b8a$ce1cf9a0$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Brett, >>So, if the UAS receives a re-INVITE w/o SDP, >>and then also receives an >>ACK w/o SDP, what does it do? For the initial >>INVITE, it probably releases the call, >>because it's a protocol error. Does the UAS do the >>same here, or should it assume that the UAC SDP >>has not changed? >Assuming a 2xx response was sent from UAS, >it is a protocol error per rfc2543bis-04. >The resulting action is undefined. > >Once the offer/answer SDP usage is split >into a separate draft, I assume that the >resulting action will remain undefined to >avoid constantly defining how devices >should handle each and every protocol >violation. > >With that said, I assume most devices >will release the call. Others might >assume the SDP hasn't changed. Others >will trigger a reinvite with SDP to >obtain the protocol violators SDP. I guess using a re-INVITE is also one of the options if the UAS doesn't accept the SDP in the ACK? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 02:30:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28414 for ; Wed, 3 Oct 2001 02:30:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18395; Wed, 3 Oct 2001 02:19:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18370 for ; Wed, 3 Oct 2001 02:19:28 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27598 for ; Wed, 3 Oct 2001 02:19:24 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f936JKC02563; Wed, 3 Oct 2001 08:19:20 +0200 (MEST) Received: from lmf.ericsson.se (lmf03754pc.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f936JKN15523; Wed, 3 Oct 2001 09:19:20 +0300 (EET DST) Message-ID: <3BBAADE5.C15C4DDF@lmf.ericsson.se> Date: Wed, 03 Oct 2001 09:19:17 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <000b01c14b8a$ce1cf9a0$2b01a8c0@broadsoft.com> <3BBAA2E1.F8331F5F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Another question related to this SDP-in-the-ACK issue. Again, assume that the UAS receives a re-INVITE w/o SDP. It sends back 200 OK with its original SDP. This far, everything is fine. Then the UAC MUST send its SDP in the ACK. Again, if the UAS accepts it everything is fine. In a previous mail, I asked about what the UAS shall do if it does not accept the SDP in the ACK. The reason the UAS doesn't accept it may be because it simply doesn't have resources. Then, if we have a scenario (someone mentioned some 3pcc cases) where the SDP must be sent in the ACK, how does the UAC ADD streams in those cases? I assume that the number of m= lines in the ACK must match the number in the 200 OK from the UAS, so the UAC is not allowed to add more streams in the ACK SDP. And, IF the UAC would be allowed to do that, how does the UAS then send back a SDP with a new SDP, where the new m= line is also matched? Using re-INVITE??? Regards, Christer Holmberg Ericsson Finland A similar case is if the SDP in the ACK contains NEW m= lines. I would say that is a protocol error Christer Holmberg wrote: > > Hi Brett, > > >>So, if the UAS receives a re-INVITE w/o SDP, > >>and then also receives an > >>ACK w/o SDP, what does it do? For the initial > >>INVITE, it probably releases the call, > >>because it's a protocol error. Does the UAS do the > >>same here, or should it assume that the UAC SDP > >>has not changed? > >Assuming a 2xx response was sent from UAS, > >it is a protocol error per rfc2543bis-04. > >The resulting action is undefined. > > > >Once the offer/answer SDP usage is split > >into a separate draft, I assume that the > >resulting action will remain undefined to > >avoid constantly defining how devices > >should handle each and every protocol > >violation. > > > >With that said, I assume most devices > >will release the call. Others might > >assume the SDP hasn't changed. Others > >will trigger a reinvite with SDP to > >obtain the protocol violators SDP. > > I guess using a re-INVITE is also one of the options if the UAS doesn't > accept the SDP in the ACK? > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 03:19:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01719 for ; Wed, 3 Oct 2001 03:19:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19117; Wed, 3 Oct 2001 02:55:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19088 for ; Wed, 3 Oct 2001 02:55:21 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00531 for ; Wed, 3 Oct 2001 02:55:06 -0400 (EDT) From: stoshniwal@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f936tbA06251; Wed, 3 Oct 2001 12:25:38 +0530 (IST) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by hsssun01.hss.hns.com (8.8.8+Sun/8.8.8) with SMTP id MAA06937; Wed, 3 Oct 2001 12:33:43 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256ADA.00256970 ; Wed, 3 Oct 2001 12:18:38 +0530 X-Lotus-FromDomain: HSSBLR To: Christer Holmberg cc: sip@ietf.org, brett@broadsoft.com Message-ID: <65256ADA.002568E9.00@sampark.hss.hns.com> Date: Wed, 3 Oct 2001 12:18:36 +0530 Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer, Please find comments inline. > Another question related to this SDP-in-the-ACK issue. > Again, assume that the UAS receives a re-INVITE w/o SDP. > It sends back 200 OK with its original SDP. This far, > everything is fine. Just an aside, I suppose you are referring to the negotiated SDP in the original session and not to the original capabilities of the UAS. (This was what Rosenberg had proposed in the beginning of this thread...) > Then the UAC MUST send its SDP in the ACK. Again, if > the UAS accepts it everything is fine. > > In a previous mail, I asked about what the UAS shall do > if it does not accept the SDP in the ACK. The reason the > UAS doesn't accept it may be because it simply doesn't have > resources. Is this really possible? Because till the re-INVITE from the other end this very UAS was in session with the other entity. If it had resources for an established call in the first hand, it should have them at time of the re-INVITE w/o SDP. Is it not? So assuming that the UAS proposes already negotiated SDP to the UAC who has not sent any SDP in the re-INVITE AND if the UAC accepts these media streams, resource reservation for the original call should suffice for the re-INVITE as well, is it not? > Then, if we have a scenario (someone mentioned some 3pcc > cases) where the SDP must be sent in the ACK, how does the > UAC ADD streams in those cases? To add streams, the UAC SHOULD do a re-INVITE instead of using the ACK for this purpose. Any counter-offer should not be made in the ACK either case, whether the INVITE came with SDP or not for the same reason as what you mentioned: The UAS would have no way of telling the UAC whether it accepted the added streams or not. > I assume that the number of m= lines in the ACK must match > the number in the 200 OK from the UAS, so the UAC is not > allowed to add more streams in the ACK SDP. I guess this should be true as even in the offer/answer model of SDP in INVITE and negotiated SDP in 200 OK, the 200 OK should have the same lines as the INVITE. > And, IF the UAC would be allowed to do that, how does the > UAS then send back a SDP with a new SDP, where the new m= > line is also matched? Using re-INVITE??? No, this should not be allowed. For an offer that is made in 200 OK, the ACK should just contain a response to the offer and not any additional streams. Regards, Siddharth. ================================= Siddharth Toshniwal Software Engineer Hughes Software Systems, Bangalore http://www.hssworld.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 06:42:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06290 for ; Wed, 3 Oct 2001 06:42:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24991; Wed, 3 Oct 2001 06:13:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24960 for ; Wed, 3 Oct 2001 06:13:34 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05708 for ; Wed, 3 Oct 2001 06:13:29 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 03:11:53 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Flemming Andreasen'" , Romel Khan Cc: byerly@cisco.com, sip@ietf.org Subject: RE: [Sip] What is the mapping of ANI II digits to rpi-np? Date: Wed, 3 Oct 2001 03:11:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Flemming, I think authentication and generation are unrelated to the argument - it is a case of representation and scope. The RPI header (which includes both the URL and RPI header parameters) can be signed/protected under the proposed privacy framework. The appropriate RPI headers can be added and signed by any entity that has the appropriate information along the call path (eg logically in this case the originating SS7-SIP gateway). What is the rpi-np parameter really trying to accomplish? If it is trying to re-invent the ANI II wheel then rpi-np does not make sufficient sense (IMO). The OLI refers to a telephone subscriber and therefore placing that information with the telephone subscriber as Romel suggested is the right way to go. If the rpi-np is trying to do solve some more generic "where is this entity calling from" question, then we need to examine and describe more fully what it is trying to accomplish and how it is to be used. [Otherwise we get a scheme that is not helpful to those want to do SS7 entity identification (without fully-blown SIP-T) and also may not be useful for those who do not need to solve the above problem.] Hence, if we use the oli tel: url parameter as Romel suggested (in addition to any RPI parameters), then we largely free ourselves from the burden of needing bidirectional mappings for SS7 when trying to come up with a useful scheme for rpi-np. Regards, Robert. P.S. Mike, I believe Romel is actually suggesting the use of numeric values for the oli tel: url parameter. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Wednesday, October 03, 2001 1:10 AM > To: Romel Khan > Cc: byerly@cisco.com; sip@ietf.org > Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? > > > > > Romel Khan wrote: > > > How about do something like: > > From: > > where oli = originating line information = ani-ii > > > > Who adds the ANI II ? How do you know you can trust it ? > > -- Flemming > > > > > > This encloses the II information within telephone URL > consistent with > > RFC2806 and makes it independent of SIP. > > > > -----Original Message----- > > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > > Sent: Saturday, September 29, 2001 8:05 PM > > To: byerly@cisco.com; sip@ietf.org > > Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? > > > > To all, > > > > In a message dated 9/28/01 5:11:08 PM Eastern Daylight Time, > > byerly@cisco.com > > writes: > > > > << Hi guys, > > > > I had initially sent out a question on this issue and received no > > responses; so I'm trying again... :^) > > > > I'm trying to understand the appropriate translation of > ANI II digits to > > their SIP equivalent. However, when > > I try to match the currently defined ANI II digits from > > http://www.nanpa.com/number_resource_info/ani_ii_assignments.html > > against the keywords defined in > > Appendix A of draft-ietf-sip-privacy-02.txt, it appears to > be a sparse, > > non-invertible mapping. > > > > So, I have a few questions: > > 1) Is there a more recent version of this syntax? > > 2) Could someone define a less sparse, invertible mapping as a best > > current practice? > > 3) Should we instead just define a new tag such as, > ";ani-ii=number" ? > > 4) Other ideas? >> > > > > < > It seems best to use your suggestion 3 - simply define a tag for > > "ani-ii=number" and use the currently defined numbers, not > some newly > > invented list of keywords that have unknown meanings. Let's > not reinvent the > > > > wheel! > > > > Mike Pierce > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 06:43:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06301 for ; Wed, 3 Oct 2001 06:43:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24240; Wed, 3 Oct 2001 05:51:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24209 for ; Wed, 3 Oct 2001 05:51:09 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05050 for ; Wed, 3 Oct 2001 05:51:04 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f939ovC16420; Wed, 3 Oct 2001 11:50:57 +0200 (MEST) Received: from lmf.ericsson.se (lmf03754pc.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f939oul23383; Wed, 3 Oct 2001 12:50:56 +0300 (EET DST) Message-ID: <3BBADF7C.CB7AE5@lmf.ericsson.se> Date: Wed, 03 Oct 2001 12:50:52 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: stoshniwal@hss.hns.com CC: sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.002568E9.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, My comments. >>Another question related to this SDP-in-the-ACK issue. >>Again, assume that the UAS receives a re-INVITE w/o SDP. >>It sends back 200 OK with its original SDP. This far, >>everything is fine. >Just an aside, I suppose you are referring to the negotiated >SDP in the original session and not to the original >capabilities of the UAS. I am talking about a re-INVITE case, ie where the session already has been established. >>Then the UAC MUST send its SDP in the ACK. Again, if >>the UAS accepts it everything is fine. >> >>In a previous mail, I asked about what the UAS shall do >>if it does not accept the SDP in the ACK. The reason the >>UAS doesn't accept it may be because it simply doesn't have >>resources. >Is this really possible? Because till the re-INVITE from the >other end this very UAS was in session with the other entity. >If it had resources for an established call in the first hand, >it should have them at time of the re-INVITE w/o SDP. Is it >not? I am sure this could happen, for example if there is some codec change etc involved. Also, there may be some SDP attributes, which require some kind of resources, included. >So assuming that the UAS proposes already negotiated SDP >to the UAC who has not sent any SDP in the re-INVITE AND if >the UAC accepts these media streams, resource reservation >for the original call should suffice for the re-INVITE as >well, is it not? Not, if the UAC changes something in the SDP it sends in the ACK. >>Then, if we have a scenario (someone mentioned some 3pcc >>cases) where the SDP must be sent in the ACK, how does the >>UAC ADD streams in those cases? >To add streams, the UAC SHOULD do a re-INVITE instead of >using the ACK for this purpose. Any counter-offer should not >be made in the ACK either case, whether the INVITE came with >SDP or not for the same reason as what you mentioned: The >UAS would have no way of telling the UAC whether it accepted >the added streams or not. I know, but I wanted to bring the case up because there seems to be scenarios where the SDP must be sent in the ACK. So, my questions is if adding of strems is not possible for those scenarios. >>I assume that the number of m= lines in the ACK must match >>the number in the 200 OK from the UAS, so the UAC is not >>allowed to add more streams in the ACK SDP. >I guess this should be true as even in the offer/answer model >of SDP in INVITE and negotiated SDP in 200 OK, the 200 OK >should have the same lines as the INVITE. I agree. But, like I said, how do we add streams? >>And, IF the UAC would be allowed to do that, how does the >>UAS then send back a SDP with a new SDP, where the new m= >>line is also matched? Using re-INVITE??? >No, this should not be allowed. For an offer that is made in >200 OK, the ACK should just contain a response to the offer >and not any additional streams. "Should" doesn't work here. If it doesn't work, it shall be "MUST NOT". Thanks for your comments! Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 07:06:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07030 for ; Wed, 3 Oct 2001 07:06:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25250; Wed, 3 Oct 2001 06:28:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25151 for ; Wed, 3 Oct 2001 06:28:27 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06013 for ; Wed, 3 Oct 2001 06:28:14 -0400 (EDT) From: stoshniwal@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f93ASf316410; Wed, 3 Oct 2001 15:58:42 +0530 (IST) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by hsssun01.hss.hns.com (8.8.8+Sun/8.8.8) with SMTP id QAA01404; Wed, 3 Oct 2001 16:06:53 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256ADA.0038ED06 ; Wed, 3 Oct 2001 15:51:46 +0530 X-Lotus-FromDomain: HSSBLR To: Christer Holmberg cc: sip@ietf.org, brett@broadsoft.com Message-ID: <65256ADA.0038EC7D.00@sampark.hss.hns.com> Date: Wed, 3 Oct 2001 15:51:45 +0530 Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer, Thanks for the reply. Please find my comments inline again... >>> Another question related to this SDP-in-the-ACK issue. >>> Again, assume that the UAS receives a re-INVITE w/o SDP. >>> It sends back 200 OK with its original SDP. This far, >>> everything is fine. >>> >> Just an aside, I suppose you are referring to the negotiated >> SDP in the original session and not to the original >> capabilities of the UAS. >> > I am talking about a re-INVITE case, ie where the session > already has been established. Same here :) Lets make it clear with an example: the session is established with 2 streams being accepted originally by the UAS (say, Mu-law and ADPCM) What I meant to say was this: The UAS MUST reply back to a re-INVITE without SDP with only these 2 streams (Mu-law and ADPCM) in the 200 OK to this re-INVITE regardless of whether the UAS actually supports more streams than just these 2. (this is what Rosenberg had proposed as the open issue). Since these 2 were accepted the first time when INVITE-OK-ACK took place, the UAC which initiated the re-INVITE should be supporting the same still. =========================================================== >>> Then the UAC MUST send its SDP in the ACK. Again, if >>> the UAS accepts it everything is fine. >>> >>> In a previous mail, I asked about what the UAS shall do >>> if it does not accept the SDP in the ACK. The reason the >>> UAS doesn't accept it may be because it simply doesn't have >>> resources. >>> >> Is this really possible? Because till the re-INVITE from the >> other end this very UAS was in session with the other entity. >> If it had resources for an established call in the first hand, >> it should have them at time of the re-INVITE w/o SDP. Is it >> not? >> > I am sure this could happen, for example if there is > some codec change etc involved. Also, there may be some > SDP attributes, which require some kind of resources, > included. =========================================================== >> So assuming that the UAS proposes already negotiated SDP >> to the UAC who has not sent any SDP in the re-INVITE AND if >> the UAC accepts these media streams, resource reservation >> for the original call should suffice for the re-INVITE as >> well, is it not? >> > Not, if the UAC changes something in the SDP it sends in > the ACK. Precisely. I agree. The UAC MUST NOT make a proposal for media in the ACK in any case (!) Whether it is to add a new stream or any other modification, if the modification is not proposed in the INVITE, it MUST NOT be proposed in the ACK. =========================================================== >>> Then, if we have a scenario (someone mentioned some 3pcc >>> cases) where the SDP must be sent in the ACK, how does the >>> UAC ADD streams in those cases? >>> >> To add streams, the UAC SHOULD do a re-INVITE instead of >> using the ACK for this purpose. Any counter-offer should not >> be made in the ACK either case, whether the INVITE came with >> SDP or not for the same reason as what you mentioned: The >> UAS would have no way of telling the UAC whether it accepted >> the added streams or not. >> > I know, but I wanted to bring the case up because there seems > to be scenarios where the SDP must be sent in the ACK. So, > my questions is if adding of strems is not possible for those > scenarios. >>> I assume that the number of m= lines in the ACK must match >>> the number in the 200 OK from the UAS, so the UAC is not >>> allowed to add more streams in the ACK SDP. >> I guess this should be true as even in the offer/answer model >> of SDP in INVITE and negotiated SDP in 200 OK, the 200 OK >> should have the same lines as the INVITE. > I agree. But, like I said, how do we add streams? No, it is not possible to add streams directly in the ACK. I have a feeling we both are on consensus with that, are we not? :) To do so, the end-point will need another re-INVITE. It will need to store the negotiated session parameters after the first INVITE-OK-ACK and add to the same in the SDP of the re-INVITE. No other go... as far as I can see. This re-INVITE that was sent w/o SDP served no purpose for adding streams as such. All it would tell you were the current streams with which the call was established. (Even for this actually, a re-INVITE w/o SDP should not be used) =========================================================== >>> And, IF the UAC would be allowed to do that, how does the >>> UAS then send back a SDP with a new SDP, where the new m= >>> line is also matched? Using re-INVITE??? >>> >> No, this should not be allowed. For an offer that is made in >> 200 OK, the ACK should just contain a response to the offer >> and not any additional streams. >> > "Should" doesn't work here. If it doesn't work, it shall > be "MUST NOT". Quite frankly, I'm all for saying "so be it" :) A new media proposal in ACK for adding streams to the call does not really make sense to me. It MUST NOT be done. But I might be mistaken... so anyone who feels its necessary in the ACK instead of a new re-INVITE can please correct me. Best Regards, Siddharth. ================================= Siddharth Toshniwal Software Engineer Hughes Software Systems, Bangalore http://www.hssworld.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 07:39:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08158 for ; Wed, 3 Oct 2001 07:39:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26742; Wed, 3 Oct 2001 07:13:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26671 for ; Wed, 3 Oct 2001 07:13:06 -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 HAA07265; Wed, 3 Oct 2001 07:13:03 -0400 (EDT) Message-Id: <200110031113.HAA07265@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Oct 2001 07:13:02 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-midcom-stun-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : STUN - Simple Traversal of UDP Through NATs Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy Filename : draft-rosenberg-midcom-stun-00.txt Pages : 20 Date : 02-Oct-01 Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the nat. STUN works with nearly all existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. The STUN protocol is very simple, being almost identical to echo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rosenberg-midcom-stun-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-rosenberg-midcom-stun-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: <20011002120839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-midcom-stun-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-midcom-stun-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011002120839.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 07:59:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08833 for ; Wed, 3 Oct 2001 07:59:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26836; Wed, 3 Oct 2001 07:13:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26804 for ; Wed, 3 Oct 2001 07:13: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 HAA07358; Wed, 3 Oct 2001 07:13:34 -0400 (EDT) Message-Id: <200110031113.HAA07358@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Oct 2001 07:13:34 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-07.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-07.txt Pages : 28 Date : 02-Oct-01 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new general headers, Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-session-timer-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-timer-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011002120935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011002120935.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 08:30:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10437 for ; Wed, 3 Oct 2001 08:30:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28452; Wed, 3 Oct 2001 08:12:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28421 for ; Wed, 3 Oct 2001 08:12:09 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09664 for ; Wed, 3 Oct 2001 08:12:05 -0400 (EDT) Received: from hermes.ee.surrey.ac.uk ([131.227.88.10] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15okse-0005y1-00 for sip@ietf.org; Wed, 03 Oct 2001 13:12:04 +0100 Received: from ees2ll (helo=localhost) by hermes.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 15okse-0007Z3-00 for sip@ietf.org; Wed, 3 Oct 2001 13:12:04 +0100 Date: Wed, 3 Oct 2001 13:12:04 +0100 (BST) From: Lei Liang X-Sender: ees2ll@hermes.ee.surrey.ac.uk To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15okse-0005y1-00*v7.yM1wVfEw* http://duncanthrax.net/exiscan/ Subject: [Sip] greener question for "contact" header field Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org hello, everyone, I see the "contact" header is used to specify the sender's addr. does the caller and callee always use this addr to communicate after they get it? looks it's more efficient to use the addr in "contact" header but not the one in "To" as the destination addr, doesn't it? another question is the RFC said using the "contact" addr can avoid the proxies. but it's impossible for me because it has to pass firewall, a kind of proxy, if the caller or callee is behind it. am I right? thanks a lot for ur reading. cheers. lei _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 09:01:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12294 for ; Wed, 3 Oct 2001 09:01:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27634; Wed, 3 Oct 2001 07:32:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27605 for ; Wed, 3 Oct 2001 07:32:10 -0400 (EDT) Received: from phoebe.eim.surrey.ac.uk (IDENT:exim@phoebe.eim.surrey.ac.uk [131.227.74.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07950 for ; Wed, 3 Oct 2001 07:32:07 -0400 (EDT) Received: from hermes.ee.surrey.ac.uk ([131.227.88.10] ident=exim) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15okG0-000647-00 for sip@ietf.org; Wed, 03 Oct 2001 12:32:08 +0100 Received: from ees2ll (helo=localhost) by hermes.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 15okFu-0007VA-00 for sip@ietf.org; Wed, 3 Oct 2001 12:32:02 +0100 Date: Wed, 3 Oct 2001 12:32:02 +0100 (BST) From: Lei Liang X-Sender: ees2ll@hermes.ee.surrey.ac.uk To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15okG0-000647-00*4ZBNbutGQQ.* http://duncanthrax.net/exiscan/ Subject: [Sip] newbie's question of "tag" parameter Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, everybody, when I was reading RFC2543, I saw "tag" parameter may be added in "from" and "to" general hearders. it was said that "tag" was used to distinguish the user who has more than one instances with the same sip addr, e.g. mobile and telephone. does it mean every instance has one unique URI to identify itself from others? then what happens if one user change his instance from a telephone to a mobile during a call or use both of them for the same call-ID at the same time. can he do that or not? if can, does the sip message have to be send to two destinations which are distinguished by using "tag" para? any instruction will be really appreciated. thx a lot. cheers. lei _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 09:05:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12540 for ; Wed, 3 Oct 2001 09:05:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29121; Wed, 3 Oct 2001 08:33:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29097 for ; Wed, 3 Oct 2001 08:33:50 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10668 for ; Wed, 3 Oct 2001 08:33:46 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f93CXhC03269; Wed, 3 Oct 2001 14:33:43 +0200 (MEST) Received: from lmf.ericsson.se (lmf03754pc.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f93CXgl29391; Wed, 3 Oct 2001 15:33:43 +0300 (EET DST) Message-ID: <3BBB05A3.45F73E32@lmf.ericsson.se> Date: Wed, 03 Oct 2001 15:33:39 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: stoshniwal@hss.hns.com CC: sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.0038EC7D.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>>>Another question related to this SDP-in-the-ACK issue. >>>>Again, assume that the UAS receives a re-INVITE w/o SDP. >>>>It sends back 200 OK with its original SDP. This far, >>>>everything is fine. >>>> >>>Just an aside, I suppose you are referring to the negotiated >>>SDP in the original session and not to the original >>>capabilities of the UAS. >>> >>I am talking about a re-INVITE case, ie where the session >>already has been established. > >Same here :) Lets make it clear with an example: the session >is established with 2 streams being accepted originally by the >UAS (say, Mu-law and ADPCM) What I meant to say was this: > >The UAS MUST reply back to a re-INVITE without SDP with only >these 2 streams (Mu-law and ADPCM) in the 200 OK to this re-INVITE >regardless of whether the UAS actually supports more streams than >just these 2. (this is what Rosenberg had proposed as the open >issue). Yes, and so far everything is ok :) >Since these 2 were accepted the first time when INVITE-OK-ACK >took place, the UAC which initiated the re-INVITE should be >supporting the same still. True. Again, the issue was if the UAC in the ACK then ADD new streams. >>>So assuming that the UAS proposes already negotiated SDP >>>to the UAC who has not sent any SDP in the re-INVITE AND if >>>the UAC accepts these media streams, resource reservation >>>for the original call should suffice for the re-INVITE as >>>well, is it not? >>> >>Not, if the UAC changes something in the SDP it sends in >>the ACK. > >Precisely. I agree. The UAC MUST NOT make a proposal for >media in the ACK in any case (!) Whether it is to add a new >stream or any other modification, if the modification is not >proposed in the INVITE, it MUST NOT be proposed in the ACK. That sounds very fine to me, IF the SDP in the ACK MUST be the same as the original SDP. BUT, can someone then give a case where this is really needed? If the UAC isn't able to send the original SDP in the re-INVITE, how can it suddenly then be able to send it in the ACK??????????????? I mean, if it MUST send the original SDP, it doesn't matter what it receives in the 200 response to the re-INVITE... However, my understanding was that the UAC should be able to modify the existing streams in the ACK SDP (but not add new streams). Is that wrong? >>>>Then, if we have a scenario (someone mentioned some 3pcc >>>>cases) where the SDP must be sent in the ACK, how does the >>>>UAC ADD streams in those cases? >>>> >>>To add streams, the UAC SHOULD do a re-INVITE instead of >>>using the ACK for this purpose. Any counter-offer should not >>>be made in the ACK either case, whether the INVITE came with >>>SDP or not for the same reason as what you mentioned: The >>>UAS would have no way of telling the UAC whether it accepted >>>the added streams or not. >>> >>I know, but I wanted to bring the case up because there seems >>to be scenarios where the SDP must be sent in the ACK. So, >>my questions is if adding of strems is not possible for those >>scenarios. > >>>>I assume that the number of m= lines in the ACK must match >>>>the number in the 200 OK from the UAS, so the UAC is not >>>>allowed to add more streams in the ACK SDP. >>>I guess this should be true as even in the offer/answer model >>>of SDP in INVITE and negotiated SDP in 200 OK, the 200 OK >>>should have the same lines as the INVITE. >>I agree. But, like I said, how do we add streams? > >No, it is not possible to add streams directly in the ACK. >I have a feeling we both are on consensus with that, are we >not? At least I am :) But, again, my concern is if there IS a scenario where the UAC DOES add streams in the ACK SDP? >To do so, the end-point will need another re-INVITE. >It will need to store the negotiated session parameters after >the first INVITE-OK-ACK and add to the same in the SDP of >the re-INVITE. No other go... as far as I can see. I couldn't agree more :) >This re-INVITE that was sent w/o SDP served no purpose for >adding streams as such. All it would tell you were the current >streams with which the call was established. (Even for this >actually, a re-INVITE w/o SDP should not be used) Yes, and that is related to my question: what is 200/ACK SDP exchange really needed for, if no party is allowed to change anything in the SDPs? What is it that can't be done with a re-INVITE/200 SDP exchange?????? >>>>And, IF the UAC would be allowed to do that, how does the >>>>UAS then send back a SDP with a new SDP, where the new m= >>>>line is also matched? Using re-INVITE??? >>>> >>>No, this should not be allowed. For an offer that is made in >>>200 OK, the ACK should just contain a response to the offer >>>and not any additional streams. >>> >>"Should" doesn't work here. If it doesn't work, it shall >> be "MUST NOT". > >Quite frankly, I'm all for saying "so be it" :) A new media >proposal in ACK for adding streams to the call does not really >make sense to me. Again, it is not only about adding streams, but also about modifying existing ones. >It MUST NOT be done. But I might be mistaken... >so anyone who feels its necessary in the ACK instead of a new >re-INVITE can please correct me. Again, my understanding is that there ARE some scenarios where the re-INVITE with SDP can't be used, and in those cases ACK with SDP must be used, and that is the reason I brought this up in the first place. Thanks for your comments! Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 09:05:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12554 for ; Wed, 3 Oct 2001 09:05:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29416; Wed, 3 Oct 2001 08:41:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29385 for ; Wed, 3 Oct 2001 08:41:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11016 for ; Wed, 3 Oct 2001 08:41:29 -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 IAA14148 for ; Wed, 3 Oct 2001 08:41:00 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA05704 for ; Wed, 3 Oct 2001 08:41:01 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Oct 2001 08:41:00 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57C2DB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" Date: Wed, 3 Oct 2001 08:40:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Friendly Reminder from your List Manager Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I few friendly reminders from those who manage high volume IETF lists on a volunteer basis: 1. Anything that causes bounces is usually dealt with right away, by forced unsubscription or setting the subscription to nomail. I make an exception sometimes for obvious routing goofs (like all cisco.com or ericsson.com addresses start bouncing). Since you are bouncing, I can't send you an email and tell you what I did. When I come in the morning and have 25 or 50 bounce messages from one or two addresses, I'm not in much of a mood to be very tolerant. If you change email addresses, or stop being involved suddenly, I'd appreciate it if you would unsubscribe yourself. 2. The list is set up to ask me before forwarding an email longer than 40K. I usually reject such posts. Usually this is caused by one of two things: a huge MIME section or an attachment. The former is often a result of too many people replying to a thread leaving all the prior messages on the thread, and making it an HTML email. See the next point on HTML. For the latter, put the attachment on an accessible website, and post an email with a URL to the page. 3. It's pretty clear that a very large percentage of list subscribers use email readers that handle HTML email. However, we have some who don't. It is discourteous to send HTML formated mail to the list, and I ask that you don't. Most email clients will allow you to send plain unformatted ASCII text. Do that. We know that some sites are configured to always send HTML. If your site is, we understand what you do with your client is overriden by the site, don't sweat it. I know I have often replied to an HTML email and forgotten to turn it to plain ASCII, so I won't jump on anyone for this, but please try to remember. 4. There is never a reason for you to send a message to both SIP and SIPPING, or for that matter to any two of sip, sipping or sip-implementors. Pick one. If you really know what is going on, the right one is obvious. If you are unsure, you are almost always asking a question of those who do, and those most often belong on sip-implementors, so use that as the default choice. When you send to multiple lists, the folks that respond are usually subscribed to all the lists, and they get multiple copies. Annoying those who would help you is not a wise choice. If you reply to such a message, make sure you reply to the right list. I always send a reminder about posting to multiple lists to the offender. I do it privately, not copying the list. You don't have to. This message would, of course be an exception :) Your list-monger Brian _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 12:54:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22031 for ; Wed, 3 Oct 2001 12:54:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07893; Wed, 3 Oct 2001 12:19:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07862 for ; Wed, 3 Oct 2001 12:19:46 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20358 for ; Wed, 3 Oct 2001 12:19:42 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GKN00GJN1B6HS@firewall.wcom.com> for sip@ietf.org; Wed, 3 Oct 2001 16:18:42 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GKN00H011ASHI@dgismtp01.wcomnet.com>; Wed, 03 Oct 2001 16:18:41 +0000 (GMT) Received: from wcom.com ([166.42.32.168]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GKN00FLS1ANPH@dgismtp01.wcomnet.com>; Wed, 03 Oct 2001 16:18:25 +0000 (GMT) Date: Wed, 03 Oct 2001 11:19:09 -0500 From: Alan Johnston Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? To: "Fairlie-Cuninghame, Robert" Cc: "'Flemming Andreasen'" , Romel Khan , byerly@cisco.com, sip@ietf.org Message-id: <3BBB3A7D.E84587B8@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert, See my comments below. Alan Johnston sip:alan@siptest.wcom.com "Fairlie-Cuninghame, Robert" wrote: > Flemming, > > I think authentication and generation are unrelated to the argument - it is > a case of representation and scope. The RPI header (which includes both the > URL and RPI header parameters) can be signed/protected under the proposed > privacy framework. The appropriate RPI headers can be added and signed by > any entity that has the appropriate information along the call path (eg > logically in this case the originating SS7-SIP gateway). > > What is the rpi-np parameter really trying to accomplish? The main purpose of the rpi-np is to allow some of the identification information about a PSTN endpoint originator that is available in the PSTN to be available in SIP if the call routes PSTN to SIP. For the PSTN to SIP to PSTN case, only SIP-T will work. The intent was to map only the information that might be useful to a SIP network in routing a call. For example, knowing that the call is coming from a payphone could trigger some service logic in a proxy that could cause INVITE routing to change. However, coin deposit signaling information is not at all relevant to routing the INVITE. (If one wants to build SIP payphones, there are far more elegant ways than reusing coin signaling in the PSTN.) > If it is trying to > re-invent the ANI II wheel then rpi-np does not make sufficient sense (IMO). > The OLI refers to a telephone subscriber and therefore placing that > information with the telephone subscriber as Romel suggested is the right > way to go. This is not the intent. Also, note that simply saying ii=53 does not work, as 53 may have different meaning depending on the flavor of ISUP being used. > > > If the rpi-np is trying to do solve some more generic "where is this entity > calling from" question, then we need to examine and describe more fully what > it is trying to accomplish and how it is to be used. [Otherwise we get a > scheme that is not helpful to those want to do SS7 entity identification > (without fully-blown SIP-T) and also may not be useful for those who do not > need to solve the above problem.] > > Hence, if we use the oli tel: url parameter as Romel suggested (in addition > to any RPI parameters), then we largely free ourselves from the burden of > needing bidirectional mappings for SS7 when trying to come up with a useful > scheme for rpi-npi. > > > Regards, > > Robert. > > P.S. Mike, I believe Romel is actually suggesting the use of numeric values > for the oli tel: url parameter. Numeric values do not make sense, as they have only local significance. > > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Wednesday, October 03, 2001 1:10 AM > > To: Romel Khan > > Cc: byerly@cisco.com; sip@ietf.org > > Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? > > > > > > > > > > Romel Khan wrote: > > > > > How about do something like: > > > From: > > > where oli = originating line information = ani-ii > > > > > > > Who adds the ANI II ? How do you know you can trust it ? > > > > -- Flemming > > > > > > > > > > This encloses the II information within telephone URL > > consistent with > > > RFC2806 and makes it independent of SIP. > > > > > > -----Original Message----- > > > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > > > Sent: Saturday, September 29, 2001 8:05 PM > > > To: byerly@cisco.com; sip@ietf.org > > > Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? > > > > > > To all, > > > > > > In a message dated 9/28/01 5:11:08 PM Eastern Daylight Time, > > > byerly@cisco.com > > > writes: > > > > > > << Hi guys, > > > > > > I had initially sent out a question on this issue and received no > > > responses; so I'm trying again... :^) > > > > > > I'm trying to understand the appropriate translation of > > ANI II digits to > > > their SIP equivalent. However, when > > > I try to match the currently defined ANI II digits from > > > http://www.nanpa.com/number_resource_info/ani_ii_assignments.html > > > against the keywords defined in > > > Appendix A of draft-ietf-sip-privacy-02.txt, it appears to > > be a sparse, > > > non-invertible mapping. > > > > > > So, I have a few questions: > > > 1) Is there a more recent version of this syntax? > > > 2) Could someone define a less sparse, invertible mapping as a best > > > current practice? > > > 3) Should we instead just define a new tag such as, > > ";ani-ii=number" ? > > > 4) Other ideas? >> > > > > > > < > > It seems best to use your suggestion 3 - simply define a tag for > > > "ani-ii=number" and use the currently defined numbers, not > > some newly > > > invented list of keywords that have unknown meanings. Let's > > not reinvent the > > > > > > wheel! > > > > > > Mike Pierce > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 12:56:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22074 for ; Wed, 3 Oct 2001 12:56:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08000; Wed, 3 Oct 2001 12:23:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07969 for ; Wed, 3 Oct 2001 12:23:03 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20382 for ; Wed, 3 Oct 2001 12:22:58 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f93GM1q27589; Wed, 3 Oct 2001 09:22:01 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f93GMHa09986; Wed, 3 Oct 2001 09:22:17 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA12787; Wed, 3 Oct 2001 09:21:57 -0700 (PDT) Message-ID: <3BBB3BAD.5B466675@cisco.com> Date: Wed, 03 Oct 2001 12:24:14 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: Romel Khan , byerly@cisco.com, sip@ietf.org Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > Flemming, > > I think authentication and generation are unrelated to the argument - it is > a case of representation and scope. The RPI header (which includes both the > URL and RPI header parameters) can be signed/protected under the proposed > privacy framework. The appropriate RPI headers can be added and signed by > any entity that has the appropriate information along the call path (eg > logically in this case the originating SS7-SIP gateway). > Right - that was my point (as opposed to having it in the From header). > > What is the rpi-np parameter really trying to accomplish? If it is trying to > re-invent the ANI II wheel then rpi-np does not make sufficient sense (IMO). I'll defer to Alan Johnston on that. > > The OLI refers to a telephone subscriber and therefore placing that > information with the telephone subscriber as Romel suggested is the right > way to go. > For the POTS only case I agree its natural and very easy to do that. Since tel-URL's can be passed in the Remote-Party-ID header, we just define a new tel-url extension parameter and we are done (until the next ISUP parameter comes along and before we know it we transport ISUP in a tel-URL). However, the question is whether you want to do something more general ? > > If the rpi-np is trying to do solve some more generic "where is this entity > calling from" question, then we need to examine and describe more fully what > it is trying to accomplish and how it is to be used. [Otherwise we get a > scheme that is not helpful to those want to do SS7 entity identification > (without fully-blown SIP-T) and also may not be useful for those who do not > need to solve the above problem.] > I agree. > > Hence, if we use the oli tel: url parameter as Romel suggested (in addition > to any RPI parameters), then we largely free ourselves from the burden of > needing bidirectional mappings for SS7 when trying to come up with a useful > scheme for rpi-np. > As long as we are only worried about the PSTN to SIP interworking case (really a SIP-T issue then), then I agree with defining a tel-URL extension for this. -- Flemming > > Regards, > > Robert. > > P.S. Mike, I believe Romel is actually suggesting the use of numeric values > for the oli tel: url parameter. > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Wednesday, October 03, 2001 1:10 AM > > To: Romel Khan > > Cc: byerly@cisco.com; sip@ietf.org > > Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? > > > > > > > > > > Romel Khan wrote: > > > > > How about do something like: > > > From: > > > where oli = originating line information = ani-ii > > > > > > > Who adds the ANI II ? How do you know you can trust it ? > > > > -- Flemming > > > > > > > > > > This encloses the II information within telephone URL > > consistent with > > > RFC2806 and makes it independent of SIP. > > > > > > -----Original Message----- > > > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > > > Sent: Saturday, September 29, 2001 8:05 PM > > > To: byerly@cisco.com; sip@ietf.org > > > Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? > > > > > > To all, > > > > > > In a message dated 9/28/01 5:11:08 PM Eastern Daylight Time, > > > byerly@cisco.com > > > writes: > > > > > > << Hi guys, > > > > > > I had initially sent out a question on this issue and received no > > > responses; so I'm trying again... :^) > > > > > > I'm trying to understand the appropriate translation of > > ANI II digits to > > > their SIP equivalent. However, when > > > I try to match the currently defined ANI II digits from > > > http://www.nanpa.com/number_resource_info/ani_ii_assignments.html > > > against the keywords defined in > > > Appendix A of draft-ietf-sip-privacy-02.txt, it appears to > > be a sparse, > > > non-invertible mapping. > > > > > > So, I have a few questions: > > > 1) Is there a more recent version of this syntax? > > > 2) Could someone define a less sparse, invertible mapping as a best > > > current practice? > > > 3) Should we instead just define a new tag such as, > > ";ani-ii=number" ? > > > 4) Other ideas? >> > > > > > > < > > It seems best to use your suggestion 3 - simply define a tag for > > > "ani-ii=number" and use the currently defined numbers, not > > some newly > > > invented list of keywords that have unknown meanings. Let's > > not reinvent the > > > > > > wheel! > > > > > > Mike Pierce > > > > -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 12:58:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22304 for ; Wed, 3 Oct 2001 12:58:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08786; Wed, 3 Oct 2001 12:33:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08689 for ; Wed, 3 Oct 2001 12:33:28 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20823 for ; Wed, 3 Oct 2001 12:33:24 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GKN00KL51YMHI@firewall.wcom.com> for sip@ietf.org; Wed, 3 Oct 2001 16:32:47 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GKN00E011Y4NV@dgismtp04.wcomnet.com>; Wed, 03 Oct 2001 16:32:46 +0000 (GMT) Received: from wcom.com ([166.42.32.168]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GKN00D9R1XOP1@dgismtp04.wcomnet.com>; Wed, 03 Oct 2001 16:32:14 +0000 (GMT) Date: Wed, 03 Oct 2001 11:32:58 -0500 From: Alan Johnston Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np? To: Bryan Byerly Cc: sip@ietf.org Message-id: <3BBB3DBA.DA8C3395@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3BB4E459.CBE362DC@cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bryan, We have gone over the mapping issue - see the notes below by Sharma. Note that this set includes identifiers from both North America and the rest of the world, so not every token has meaning in a given environment. Also, note that since ANI has such strong billing/charging implications, mapping directly from a SIP header to the PSTN is not a good idea. As I have said in another post, using tokens instead of numbers is necessary to eliminate the regional variants on II digits. Thanks to your comments, we propose three new tokens: not-applicable, cellular-ordinary, and cellular-roaming to cover some of the cases you outlined. Thanks, Alan Johnston sip:alan@siptest.wcom.com -------- Original Message -------- Subject: II digits to SIP REMOTE-PARTY-ID NP MAPPING Date: Wed, 03 Oct 2001 11:03:27 -0500 From: Sharma Kanchinadham To: alan.johnston@wcom.com Hi Alan, I suggest that 3 new values be added to the existing Nature of Party. The 3 values are: 1. not-applicable 2. cellular-ordinary 3. cellular-roaming Here is the mapping from II digits to rpi-np 00 ordinary 01 not-applicable 02 failure 06 not-applicable 07 not-applicable 20 not-applicable 23 not-applicable 24 trans-freephone 25 trans-freephone and payphone 27 payphone 29 prison 30-32 not-applicable 34 operator 40-49 depends on the carrier's implementation 52 not-applicable 60 not-applicable 61 cellular-ordinary 62 cellular-ordinary 63 cellular-roaming 66 not-applicable 67 not-applicable 70 payphone 80-89 reserved 93 not-applicable Also the following points are to be noted: 1. The nature of party rpi-np is meant to be primary used in the PSTN to SIP direction. It is not intended to be used in the SIP to PSTN direction. Mapping to II digits towards the PSTN might invoke unintended results in the PSTN. 2. A particular II value could map to 2 values to the rpi-np. For example, II value of 25 can map to rpi-np=trans-freephone and rpi-np=payphone. Thanks , Sharma Kanchinadham IP Call Processing & Standards Worldcom sharma.kanchinadham@wcom.com Bryan Byerly wrote: > Hi guys, > > I had initially sent out a question on this issue and received no > responses; so I'm trying again... :^) > > I'm trying to understand the appropriate translation of ANI II digits to > their SIP equivalent. However, when > I try to match the currently defined ANI II digits from > http://www.nanpa.com/number_resource_info/ani_ii_assignments.html > against the keywords defined in > Appendix A of draft-ietf-sip-privacy-02.txt, it appears to be a sparse, > non-invertible mapping. > > So, I have a few questions: > 1) Is there a more recent version of this syntax? > 2) Could someone define a less sparse, invertible mapping as a best > current practice? > 3) Should we instead just define a new tag such as, ";ani-ii=number" ? > 4) Other ideas? > > Here's the sparse, non-invertible mapping that I came up with: > > ordinary 00 > residential > business > priority > hotel 06 > failure 02 > hospital > prison 29 > police > test > payphone 70 > coin 27 > payphone-public > payphone-private > coinless > restrict > coin-restrict > coinless-restrict > reserved 80-89 > operator 34, 07? > trans-freephone > isdn-res > isdn-bus > unknown > emergency > > I was specifically unable to identify a mapping for the following ANI II > digits: > 01, 20, 23, 24, 25, 30, 31, 32, 52, 60, 61, 62, 63, 66, 67, 80-89, 93 > > Here's the lists of digits as defined by www.nanpa.com: > > ANI II DIGITS: ASSIGNMENTS AS OF FEBRUARY 2, 1999 > > DIGIT PAIR > DESCRIPTION > 00 Plain Old Telephone Service (POTS) - > non-coin service requiring no special > treatment > 01 Multiparty line (more than 2) - ANI cannot be > provided on 4 or 8 party lines. The presence of > this "01" code will cause an Operator Number > Identification (ONI) function to be performed at > the distant location. The ONI feature routes the > call to a CAMA operator or to an Operator > Services System (OSS) for determination of the > calling number. > 02 ANI Failure - the originating switching system > indicates (by the "02" code), to the receiving > office that the calling station has not been > identified. If the receiving switching system > routes the call to a CAMA or Operator > Services System, the calling number may be > verbally obtained and manually recorded. If > manual operator identification is not available, > the receiving switching system (e.g., an > interLATA carrier without operator capabilities) > may reject the call. > 03-05 Unassigned > 06 Station Level Rating - The "06" digit pair is > used when the customer has subscribed to a > class of service in order to be provided with > real time billing information. For example, > hotel/motels, served by PBXs, receive detailed > billing information, including the calling party?s > room number. When the originating switching > system does not receive the detailed billing > information, e.g., room number, this "06" code > allows the call to be routed to an operator or > operator services system to obtain complete > billing information. The rating and/or billing > information is then provided to the service > subscriber. This code is used only when the > directory number (DN) is not accompanied by > an automatic room/account identification. > 07 Special Operator Handling Required - calls > generated from stations that require further > operator or Operator Services System > screening are accompanied by the "07" code. > The code is used to route the call to an > operator or Operator Services System for > further screening and to determine if the station > has a denied-originating class of service or > special routing/billing procedures. If the call is > unauthorized, the calling party will be routed to > a standard intercept message. > 08-09 Unassigned > 10 Not assignable - conflict with 10X test code > 11 Unassigned > 12-19 Not assignable - conflict with international > outpulsing code > 20 Automatic Identified Outward Dialing (AIOD) - > without AIOD, the billing number for a PBX is > the same as the PBX Directory Number (DN). > With the AIOD feature, the originating line > number within the PBX is provided for charging > purposes. If the AIOD number is available > when ANI is transmitted, code "00" is sent. If > not, the PBX DN is sent with ANI code "20". In > either case, the AIOD number is included in > the AMA record. > 21-22 Unassigned > 23 Coin or Non-Coin - on calls using database > access, e.g., 800, ANI II 23 is used to indicate > that the coin/non-coin status of the originating > line cannot be positively distinguished for ANI > purposes by the SSP. The ANI II pair 23 is > substituted for the II pairs which would > otherwise indicate that the non-coin status is > known, i.e., 00, or when there is ANI failure. > > ANI II 23 may be substituted for a valid 2-digit > ANI pair on 0-800 calls. In all other cases, ANI > II 23 should not be substituted for a valid > 2-digit ANI II pair which is forward to an SSP > from an EAEO. > > Some of the situations in which the ANI II 23 > may be sent: > > Calls from non-conforming end offices > (CAMA or LAMA types) with combined > coin/non-coin trunk groups. > 0-800 Calls > Type 1 Cellular Calls > Calls from PBX Trunks > Calls from Centrex Tie Lines > 24 Code 24 identifies a toll free service call that > has been translated to a Plain Old Telephone > Service (POTS) routable number via the toll > free database that originated for any non-pay > station. If the received toll free number is not > converted to a POTS number, the database > returns the received ANI code along with the > received toll free number. Thus, Code 24 > indicates that this is a toll free service call > since that fact can no longer be recognized > simply by examining the called address. > 25 Code 25 identifies a toll free service call that > has been translated to a Plain Old Telephone > Service (POTS) routable number via the toll > free database that originated from any pay > station, including inmate telephone service. > Specifically, ANI II digits 27, 29, and 70 will be > replaced with Code 25 under the above stated > condition. > 26 Unassigned > 27 Code 27 identifies a line connected to a pay > station which uses network provided coin > control signaling. II 27 is used to identify this > type of pay station line irrespective of whether > the pay station is provided by a LEC or a > non-LEC. II 27 is transmitted from the > originating end office on all calls made from > these lines. > 28 Unassigned > 29 Prison/Inmate Service - the ANI II digit pair 29 > is used to designate lines within a > confinement/detention facility that are intended > for inmate/detainee use and require outward > call screening and restriction (e.g., 0+ collect > only service). A confinement/detention facility > may be defined as including, but not limited to, > Federal, State and/or Local prisons, juvenile > facilities, immigration and naturalization > confinement/detention facilities, etc., which are > under the administration of Federal, State, City, > County, or other Governmental agencies. > Prison/Inmate Service lines will be identified by > the customer requesting such call screening > and restriction. In those cases where private > paystations are located in > confinement/detention facilities, and the same > call restrictions applicable to Prison/Inmate > Service required, the ANI II digit for > Prison/Inmate Service will apply if the line is > identified for Prison/Inmate Service by the > customer. > 30-32 Intercept - where the capability is provide to > route intercept calls (either directly or after an > announcement recycle) to an access tandem > with an associated Telco Operator Services > System, the following ANI codes should be > used: > > 30 Intercept (blank) - for calls to > unassigned directory number (DN) > 31 Intercept (trouble) - for calls to > directory numbers (DN) that have been > manually placed in trouble-busy state > by Telco personnel > 32 Intercept (regular) - for calls to > recently changed or disconnected > numbers > 33 Unassigned > 34 Telco Operator Handled Call - after the Telco > Operator Services System has handled a call > for an IC, it may change the standard ANI digits > to "34", before outpulsing the sequence to the > IC, when the Telco performs all call handling > functions, e.g., billing. The code tells the IC that > the BOC has performed billing on the call and > the IC only has to complete the call. > 35-39 Unassigned > 40-49 Unrestricted Use - locally determined by > carrier > 50-51 Unassigned > 52 Outward Wide Area Telecommunications > Service (OUTWATS) - this service allows > customers to make calls to a certain zone(s) or > band(s) on a direct dialed basis for a flat > monthly charge or for a charge based on > accumulated usage. OUTWATS lines can dial > station-to-station calls directly to points within > the selected band(s) or zone(s). The LEC > performs a screening function to determine the > correct charging and routing for OUTWATS > calls based on the customer?s class of service > and the service area of the call party. When > these calls are routed to the interexchange > carrier via a combined WATS-POTS trunk > group, it is necessary to identify the WATS > calls with the ANI code "52". > 53-59 Unassigned > 60 TRS - ANI II digit pair 60 indicates that the > associated call is a TRS call delivered to a > transport carrier from a TRS Provider and that > the call originated from an unrestricted line (i.e., > a line for which there are no billing restrictions). > Accordingly, if no request for alternate billing is > made, the call will be billed to the calling line. > 61 Cellular/Wireless PCS (Type 1) - The "61" digit > pair is to be forwarded to the interexchange > carrier by the local exchange carrier for traffic > originating from a cellular/wireless PCS carrier > over type 1 trunks. (Note: ANI information > accompanying digit pair "61" identifies only the > originating cellular/wireless PCS system, not > the mobile directory placing the call. > 62 Cellular/Wireless PCS (Type 2) - The "62" digit > pair is to be forwarded to the interexchange > carrier by the cellular/wireless PCS carrier > when routing traffic over type 2 trunks through > the local exchange carrier access tandem for > delivery to the interexchange carrier. (Note: > ANI information accompanying digit pair "62" > identifies the mobile directory number placing > the call but does not necessarily identify the > true call point of origin.) > 63 Cellular/Wireless PCS (Roaming) - The "63" > digit pair is to be forwarded to the > interexchange carrier by the cellular/wireless > PCS subscriber "roaming" in another > cellular/wireless PCS network, over type 2 > trunks through the local exchange carrier > access tandem for delivery to the > interexchange carrier. (Note: Use of "63" > signifies that the "called number" is used only > for network routing and should not be disclosed > to the cellular/wireless PCS subscriber. Also, > ANI information accompanying digit pair "63" > identifies the mobile directory number > forwarding the call but does not necessarily > identify the true forwarded-call point of origin.) > 64-65 Unassigned > 66 TRS - ANI II digit pair 66 indicates that the > associated call is a TRS call delivered to a > transport carrier from a TRS Provider, and that > the call originates from a hotel/motel. The > transport carrier can use this indication, along > with other information (e.g., whether the call > was dialed 1+ or 0+) to determine the > appropriate billing arrangement (i.e., bill to room > or alternate bill). > 67 TRS - ANI II digit pair 67 indicates that the > associated call is a TRS call delivered to a > transport carrier from a TRS Provider and that > the call originated from a restricted line. > Accordingly, sent paid calls should not be > allowed and additional screening, if available, > should be performed to determine the specific > restrictions and type of alternate billing > permitted. > 68-69 Unassigned > 70 Code 70 identifies a line connected to a pay > station (including both coin and coinless > stations) which does not use network provided > coin control signaling. II 70 is used to identify > this type pay station line irrespective of > whether the pay station is provided by a LEC > or a non-LEC. II 70 is transmitted from the > originating end office on all calls made from > these lines. > 71-79 Unassigned > 80-89 Reserved for Future Expansion "to" 3-digit > Code > 90-92 Unassigned > 93 Access for private virtual network types of > service: the ANI code "93" indicates, to the IC, > that the originating call is a private virtual > network type of service call. > 94 Unassigned > 95 Unassigned - conflict with Test Codes 958 and > 959 > 96-99 Unassigned > > thanks for your help, > Bryan > > Bryan J. Byerly > byerly@cisco.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 15:08:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26735 for ; Wed, 3 Oct 2001 15:08:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13218; Wed, 3 Oct 2001 14:44:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13188 for ; Wed, 3 Oct 2001 14:44:35 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25680 for ; Wed, 3 Oct 2001 14:44:31 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f93Ih08P013218 for ; Wed, 3 Oct 2001 14:43:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4A0SM94Z>; Wed, 3 Oct 2001 14:44:04 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 3 Oct 2001 14:44:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [midcom] I-D ACTION:draft-rosenberg-midcom-stun-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I suspect many people on sip are not subscribed to midcom, so you may not be aware of whats going on. There has been a proposal to add a new charter item in the midcom group to allow for traversal through nats when the nat is not application aware or midcom aware. This would be done through some protocol where a someone on the inside talks to an element on the outside. Whether to add this item to the charter is currently being discussed on the midcom list. In support of this item, I have taken the "reflector protocol" pieces of draft-rosenberg-sip-entfw-02.txt, and combined them with ideas based on work Christian and Rohan have been doing in the same area. We have come up with a joint proposal on how to meet this charter item. This proposal is a simple protocol called stun, documented in the draft below. Although the stun protocol itself is completely orthogonal to sip, sip will be one of its biggest customers. Comments and questions should be posted to the midcom list. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, October 03, 2001 7:13 AM > Cc: sip@ietf.org; midcom@ietf.org > Subject: [midcom] I-D ACTION:draft-rosenberg-midcom-stun-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : STUN - Simple Traversal of UDP Through NATs > Author(s) : J. Rosenberg, J. Weinberger, C. > Huitema, R. Mahy > Filename : draft-rosenberg-midcom-stun-00.txt > Pages : 20 > Date : 02-Oct-01 > > Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol > that allows applications to discover the presence and types of > Network Address Translators (NATs) and firewalls between them and the > public Internet. It also provides the ability for applications to > determine the public IP addresses allocated to them by the nat. STUN > works with nearly all existing NATs, and does not require any special > behavior from them. As a result, it allows a wide variety of > applications to work through existing NAT infrastructure. The STUN > protocol is very simple, being almost identical to echo. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > 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-rosenberg-midcom-stun-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-rosenberg-midcom-stun-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. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 3 19:34:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03661 for ; Wed, 3 Oct 2001 19:34:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20439; Wed, 3 Oct 2001 19:13:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20408 for ; Wed, 3 Oct 2001 19:13:55 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03110 for ; Wed, 3 Oct 2001 19:13:53 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f93NDqL64416; Wed, 3 Oct 2001 19:13:53 -0400 (EDT) Reply-To: From: "Brett Tate" To: Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Wed, 3 Oct 2001 19:14:03 -0400 Message-ID: <001201c14c61$184e06f0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BBB05A3.45F73E32@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > However, my understanding was that the UAC > should be able to modify the existing streams > in the ACK SDP (but not add new streams). > Is that wrong? You are correct. > At least I am :) But, again, my concern is > if there IS a scenario where > the UAC DOES add streams in the ACK SDP? Within the offer-answer model (both INVITE-200 and 200-ACK), it is a protocol violation to add media streams in the answer. > Yes, and that is related to my question: > what is 200/ACK SDP exchange > really needed for, if no party is allowed > to change anything in the SDPs? After a call has been established and placed on hold, a reinvite-without-sdp will likely trigger non-hold SDP in the 200 and ACK. Thus one or both SDP's have changed. > What is it that can't be done with a > re-INVITE/200 SDP exchange?????? The main reason is to avoid an SDP change loop associated with using 3PCC/B2BUA during active calls. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 00:04:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11968 for ; Thu, 4 Oct 2001 00:04:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26493; Wed, 3 Oct 2001 23:44:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26465 for ; Wed, 3 Oct 2001 23:44:48 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11301 for ; Wed, 3 Oct 2001 23:44:41 -0400 (EDT) From: stoshniwal@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f943jJp19469; Thu, 4 Oct 2001 09:15:19 +0530 (IST) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by hsssun01.hss.hns.com (8.8.8+Sun/8.8.8) with SMTP id AAA20474; Thu, 4 Oct 2001 00:39:15 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256ADA.0067D402 ; Thu, 4 Oct 2001 00:24:04 +0530 X-Lotus-FromDomain: HSSBLR To: Christer Holmberg cc: sip@ietf.org, brett@broadsoft.com Message-ID: <65256ADA.0067D2F9.00@sampark.hss.hns.com> Date: Thu, 4 Oct 2001 00:24:01 +0530 Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer, Thanks for your mail. Please find some more text inline. >> Precisely. I agree. The UAC MUST NOT make a proposal >> for media in the ACK in any case (!) Whether it is to >> add a new stream or any other modification, if the >> modification is not proposed in the INVITE, it MUST >> NOT be proposed in the ACK. > > That sounds very fine to me, IF the SDP in the ACK > MUST be the same as the original SDP. BUT, can someone > then give a case where this is really needed? If the > UAC isn't able to send the original SDP in the re-INVITE, > how can it suddenly then be able to send it in the > ACK??????????????? I mean, if it MUST send the original > SDP, it doesn't matter what it receives in the 200 > response to the re-INVITE... The ACK to re-INVITE need not have EXACTLY the same SDP as the original INVITE (please see comment below the next snip) As Jonathan had pointed out in an earlier mail, a re-INVITE without SDP is useful in some 3pcc cases. Also, if not anything else, the re-INVITE without SDP can be taken to mean "no change, keep whatever you already have established with me". Perhaps not of a lot of use, but definitely not a protocol error (!) Disallowing the re-INVITE would make it a protocol error, and I don't see why this is a must. Do you? HOWEVER, as we discussed what the UAC MUST NOT be allowed to do is to add streams in the ACK to this re-INVITE when he did not mention this addition in the re-INVITE's SDP. I can't think of a scenario in which THIS situation for stream addition would need to be done in the ACK. Perhaps, someone else should point it out immediately if at all it exists :) The general offer/answer model of SIP seems to work just fine. Offer in ACK seems like a no-no to me, for one. > However, my understanding was that the UAC should be > able to modify the existing streams in the ACK SDP > (but not add new streams). Is that wrong? Yes, you are right. As I understood the recent thread on re-INVITE SDP, modifying existing streams IS allowed. In the ACK to the re-INVITE (w/o SDP) that we are talking about, the UAC is allowed to change parameters like IP and port of the existing "originally in use" streams. I'll take a try to sum it up as of now. ======================================= As Jonathan and others had already pointed out... 1. Re-INVITES w/o SDP are useful in some scenarios. 2. Since INVITEs w/o SDP are allowed, so should re-INVITEs So re-INVITEs w/o SDP ARE allowed. On reception of such a re-INVITE w/o SDP, the UAS MUST respond to the re-INVITE with the already negotiated session parameters if it remembers them (That is, it has not crashed since the session establishment. If the UAS has crashed, then it treats the INVITE as a new INVITE and responds with its entire set of capabilities since this is the best it can do, anyways). The UAC (3PCC or otherwise) MUST not use this mechanism of re-INVITEs w/o SDP to get all capabilities of the UAS. Also, the UAC MUST not propose a superset of the SDP that it received (in the 200 OK to the re-INVITE) in ACK that it sends across. This is in line with the general offer/answer model of SIP. The UAC is, however, free to modify parameters like IP or port for any of the "streams in use already". Does this sound fine to everyone? Regards, Siddharth ================================= Siddharth Toshniwal Software Engineer Hughes Software Systems, Bangalore http://www.hssworld.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 01:32:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15272 for ; Thu, 4 Oct 2001 01:32:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05164; Thu, 4 Oct 2001 01:11:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05107 for ; Thu, 4 Oct 2001 01:11:25 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13924 for ; Thu, 4 Oct 2001 01:11:21 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f945BML01500; Thu, 4 Oct 2001 07:11:22 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f945BMl17091; Thu, 4 Oct 2001 08:11:22 +0300 (EET DST) Message-ID: <3BBBEF78.2E28E91E@lmf.ericsson.se> Date: Thu, 04 Oct 2001 08:11:20 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <001201c14c61$184e06f0$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>However, my understanding was that the UAC >>should be able to modify the existing streams >>in the ACK SDP (but not add new streams). >>Is that wrong? >You are correct. Good :) >>At least I am :) But, again, my concern is >>if there IS a scenario where >>the UAC DOES add streams in the ACK SDP? >Within the offer-answer model (both INVITE-200 >and 200-ACK), it is a protocol violation to >add media streams in the answer. I agree. >>Yes, and that is related to my question: >>what is 200/ACK SDP exchange >>really needed for, if no party is allowed >>to change anything in the SDPs? >After a call has been established and placed >on hold, a reinvite-without-sdp will likely >trigger non-hold SDP in the 200 and ACK. >Thus one or both SDP's have changed. I am not sure I agree on that. Isn't the 200 for a non-SDP re-INVITE supposed to return the current remote SDP, and if the call has been put on hold that should be a call-hold SDP (ie the SDP that was returned in the 200 for the call hold re-INVITE)? Thanks for your comments! Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 01:36:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15490 for ; Thu, 4 Oct 2001 01:36:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05572; Thu, 4 Oct 2001 01:20:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05543 for ; Thu, 4 Oct 2001 01:20:19 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14491 for ; Thu, 4 Oct 2001 01:20:17 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f945KHC21494; Thu, 4 Oct 2001 07:20:17 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f945KHl17395; Thu, 4 Oct 2001 08:20:17 +0300 (EET DST) Message-ID: <3BBBF18F.BFC292B1@lmf.ericsson.se> Date: Thu, 04 Oct 2001 08:20:15 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: stoshniwal@hss.hns.com CC: sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.0067D2F9.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>>Precisely. I agree. The UAC MUST NOT make a proposal >>>for media in the ACK in any case (!) Whether it is to >>>add a new stream or any other modification, if the >>>modification is not proposed in the INVITE, it MUST >>>NOT be proposed in the ACK. >> >>That sounds very fine to me, IF the SDP in the ACK >>MUST be the same as the original SDP. BUT, can someone >>then give a case where this is really needed? If the >>UAC isn't able to send the original SDP in the re-INVITE, >>how can it suddenly then be able to send it in the >>ACK??????????????? I mean, if it MUST send the original >>SDP, it doesn't matter what it receives in the 200 >>response to the re-INVITE... > > >The ACK to re-INVITE need not have EXACTLY the same SDP >as the original INVITE (please see comment below the next >snip) > >As Jonathan had pointed out in an earlier mail, a >re-INVITE without SDP is useful in some 3pcc cases. I do agree, if the ACK SDP doesn't have to be the same as in the original (or, previous) INVITE. >Also, if not anything else, the re-INVITE without SDP >can be taken to mean "no change, keep whatever you >already have established with me". Perhaps not of a lot >of use, but definitely not a protocol error (!) >Disallowing the re-INVITE would make it a protocol >error, and I don't see why this is a must. Do you? No. I never said that we shouldn't allow re-INVITE without SDP :) >HOWEVER, as we discussed what the UAC MUST NOT be allowed >to do is to add streams in the ACK to this re-INVITE >when he did not mention this addition in the re-INVITE's >SDP. I can't think of a scenario in which THIS situation >for stream addition would need to be done in the ACK. Good :) >I'll take a try to sum it up as of now. >======================================= > >As Jonathan and others had already pointed out... >1. Re-INVITES w/o SDP are useful in some scenarios. >2. Since INVITEs w/o SDP are allowed, so should re-INVITEs > >So re-INVITEs w/o SDP ARE allowed. I agree. So far, so good :) >On reception of such a re-INVITE w/o SDP, the UAS MUST >respond to the re-INVITE with the already negotiated >session parameters if it remembers them (That is, it has >not crashed since the session establishment. If the UAS >has crashed, then it treats the INVITE as a new INVITE >and responds with its entire set of capabilities since >this is the best it can do, anyways). Well, well, well... This has been discussed before. Since the re-INVITE has a To-tag, the UAS will know it is not an initial INVITE - even if it doesn't have any state for the call - so it may also return 481. >The UAC (3PCC or otherwise) MUST not use this mechanism >of re-INVITEs w/o SDP to get all capabilities of the UAS. > >Also, the UAC MUST not propose a superset of the SDP >that it received (in the 200 OK to the re-INVITE) in >ACK that it sends across. This is in line with the >general offer/answer model of SIP. The UAC is, however, >free to modify parameters like IP or port for any of >the "streams in use already". > >Does this sound fine to everyone? It sounds pretty fine to me. There still is, however, the risk that the UAS will not (or can not) accept the new SDP in the ACK. Thanks for your comments! Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 07:44:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06474 for ; Thu, 4 Oct 2001 07:44:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14976; Thu, 4 Oct 2001 07:28:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14943 for ; Thu, 4 Oct 2001 07:28:06 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05964 for ; Thu, 4 Oct 2001 07:28:02 -0400 (EDT) Received: from hermes.ee.surrey.ac.uk ([131.227.88.10] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15p6fZ-0004fM-00 for sip@ietf.org; Thu, 04 Oct 2001 12:28:01 +0100 Received: from ees2ll (helo=localhost) by hermes.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 15p6fY-0001EQ-00 for sip@ietf.org; Thu, 4 Oct 2001 12:28:00 +0100 Date: Thu, 4 Oct 2001 12:28:00 +0100 (BST) From: Lei Liang X-Sender: ees2ll@hermes.ee.surrey.ac.uk To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15p6fZ-0004fM-00*x5j2CzSDj/c* http://duncanthrax.net/exiscan/ Subject: [Sip] greener question for "contact" header field Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org hello, everyone, I see the "contact" header is used to specify the sender's addr. does the caller and callee always use this addr to communicate after they get it? looks it's more efficient to use the addr in "contact" header but not the one in "To" as the destination addr, doesn't it? another question is the RFC said using the "contact" addr can avoid the proxies. but it's impossible for me because it has to pass firewall, a kind of proxy, if the caller or callee is behind it. am I right? thanks a lot for ur reading. cheers. lei _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 07:46:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06515 for ; Thu, 4 Oct 2001 07:46:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14924; Thu, 4 Oct 2001 07:27:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14893 for ; Thu, 4 Oct 2001 07:27:30 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05960 for ; Thu, 4 Oct 2001 07:27:26 -0400 (EDT) Received: from hermes.ee.surrey.ac.uk ([131.227.88.10] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15p6ez-0004ee-00 for sip@ietf.org; Thu, 04 Oct 2001 12:27:25 +0100 Received: from ees2ll (helo=localhost) by hermes.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 15p6ey-0001EL-00 for sip@ietf.org; Thu, 4 Oct 2001 12:27:24 +0100 Date: Thu, 4 Oct 2001 12:27:24 +0100 (BST) From: Lei Liang X-Sender: ees2ll@hermes.ee.surrey.ac.uk To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15p6ez-0004ee-00*RjmPgDbR2Vs* http://duncanthrax.net/exiscan/ Subject: [Sip] newbie's question of "tag" parameter Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, everybody, when I was reading RFC2543, I saw "tag" parameter may be added in "from" and "to" general hearders. it was said that "tag" was used to distinguish the user who has more than one instances with the same sip addr, e.g. mobile and telephone. does it mean every instance has one unique URI to identify itself from others? then what happens if one user change his instance from a telephone to a mobile during a call or use both of them for the same call-ID at the same time. can he do that or not? if can, does the sip message have to be send to two destinations which are distinguished by using "tag" para? any instruction will be really appreciated. thx a lot. cheers. lei _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 10:14:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13595 for ; Thu, 4 Oct 2001 10:14:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19299; Thu, 4 Oct 2001 09:35:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19268 for ; Thu, 4 Oct 2001 09:35:47 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12053 for ; Thu, 4 Oct 2001 09:35:42 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f94DZ8g25946 for ; Thu, 4 Oct 2001 14:35:09 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Thu, 4 Oct 2001 14:34:55 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 14:34:43 +0100 Message-ID: From: "Chris Hogg" To: "'Christer Holmberg'" , brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 4 Oct 2001 14:34:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14CD9.51C7D730" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C14CD9.51C7D730 Content-Type: text/plain; charset="iso-8859-1" Hi Christer, >I am not sure I agree on that. Isn't the 200 for a non-SDP re-INVITE >supposed to return the current remote SDP, and if the call has been put >on hold that should be a call-hold SDP (ie the SDP that was returned in >the 200 for the call hold re-INVITE)? I agree with this understanding. I think this is also useful in 3pcc cases whereby a controller (C) is already in session with a UA "A" but wishes to establish a session between A and a new UA "B". C sends a Re-INVITE to A with no SDP causing A to send a 200 OK with its' SDP (which will be the current remote SDP). C may then initiate a new INVITE to B with the SDP it has gleaned from A. The ACK from C to A will contain SDPb thus enabling the call signalling to go from A to B via the controller but the media path to be set up between A and B. Thus in this case, the ACK does require to modify the SDP from that of the original session but will not add any additional media streams. I suppose if the SDP from B (sent to A from C in the ACK) was inconsistent with that from A then the redirect would fail and the session would revert to the call between A and C. Just wanted to understand the issues some more - comments welcome. Thanks Regards Chris Chris Hogg Nortel Networks (UK). -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: 04 October 2001 06:11 To: brett@broadsoft.com Cc: sip@ietf.org Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Hi, >>However, my understanding was that the UAC >>should be able to modify the existing streams >>in the ACK SDP (but not add new streams). >>Is that wrong? >You are correct. Good :) >>At least I am :) But, again, my concern is >>if there IS a scenario where >>the UAC DOES add streams in the ACK SDP? >Within the offer-answer model (both INVITE-200 >and 200-ACK), it is a protocol violation to >add media streams in the answer. I agree. >>Yes, and that is related to my question: >>what is 200/ACK SDP exchange >>really needed for, if no party is allowed >>to change anything in the SDPs? >After a call has been established and placed >on hold, a reinvite-without-sdp will likely >trigger non-hold SDP in the 200 and ACK. >Thus one or both SDP's have changed. I am not sure I agree on that. Isn't the 200 for a non-SDP re-INVITE supposed to return the current remote SDP, and if the call has been put on hold that should be a call-hold SDP (ie the SDP that was returned in the 200 for the call hold re-INVITE)? Thanks for your comments! Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C14CD9.51C7D730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx

Hi Christer,

>I am not sure I agree on that. Isn't the 200 for = a non-SDP re-INVITE
>supposed to return the current remote SDP, and = if the call has been put
>on hold that should be a call-hold SDP (ie the = SDP that was returned in
>the 200 for the call hold re-INVITE)?

I agree with this understanding.  I think this = is also useful in 3pcc cases whereby a controller (C) is already in = session with a UA "A" but wishes to establish a session = between A and a new UA "B".  C sends a Re-INVITE to A = with no SDP causing A to send a 200 OK with its' SDP (which will be the = current remote SDP).  C may then initiate a new INVITE to B with = the SDP it has gleaned from A. The ACK from C to A will contain SDPb = thus enabling the call signalling to go from A to B via the controller = but the media path to be set up between A and B.  Thus in this = case, the ACK does require to modify the SDP from that of the original = session but will not add any additional media streams. I suppose if the = SDP from B (sent to A from C in the ACK) was inconsistent with that = from A then the redirect would fail and the session would revert to the = call between A and C.

Just wanted to understand the issues some more - = comments welcome.

Thanks

Regards

Chris

Chris Hogg
Nortel Networks (UK).



-----Original Message-----
From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
Sent: 04 October 2001 06:11
To: brett@broadsoft.com
Cc: sip@ietf.org
Subject: Re: [Sip] Open Issue #58: Rejected mid-call = SDP in 2xx



Hi,

>>However, my understanding was that the = UAC
>>should be able to modify the existing = streams
>>in the ACK SDP (but not add new = streams).
>>Is that wrong?
>You are correct.

Good :)

>>At least I am :) But, again, my concern = is
>>if there IS a scenario where
>>the UAC DOES add streams in the ACK = SDP?
>Within the offer-answer model (both = INVITE-200
>and 200-ACK), it is a protocol violation = to
>add media streams in the answer.

I agree.

>>Yes, and that is related to my = question:
>>what is 200/ACK SDP exchange
>>really needed for, if no party is = allowed
>>to change anything in the SDPs?
>After a call has been established and = placed
>on hold, a reinvite-without-sdp will = likely
>trigger non-hold SDP in the 200 and ACK.
>Thus one or both SDP's have changed.

I am not sure I agree on that. Isn't the 200 for a = non-SDP re-INVITE
supposed to return the current remote SDP, and if = the call has been put
on hold that should be a call-hold SDP (ie the SDP = that was returned in
the 200 for the call hold re-INVITE)?

Thanks for your comments!

Christer Holmberg
Ericsson Finland

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

------_=_NextPart_001_01C14CD9.51C7D730-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 11:07:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15576 for ; Thu, 4 Oct 2001 11:07:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20280; Thu, 4 Oct 2001 10:05:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20249 for ; Thu, 4 Oct 2001 10:05:49 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13340 for ; Thu, 4 Oct 2001 10:05:43 -0400 (EDT) From: stoshniwal@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f94E6Ea16602; Thu, 4 Oct 2001 19:36:15 +0530 (IST) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by hsssun01.hss.hns.com (8.8.8+Sun/8.8.8) with SMTP id TAA20738; Thu, 4 Oct 2001 19:44:30 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256ADB.004CD768 ; Thu, 4 Oct 2001 19:29:18 +0530 X-Lotus-FromDomain: HSSBLR To: "Chris Hogg" cc: "'Christer Holmberg'" , brett@broadsoft.com, sip@ietf.org Message-ID: <65256ADB.004CD6B5.00@sampark.hss.hns.com> Date: Thu, 4 Oct 2001 19:29:16 +0530 Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi everyone, Please find my comments below... >> I am not sure I agree on that. Isn't the 200 for a non-SDP >> re-INVITE supposed to return the current remote SDP, and if >> the call has been put on hold that should be a call-hold >> SDP (ie the SDP that was returned in the 200 for the call >> hold re-INVITE)? Just to confirm, the scenario we are talking about is User A <-----> User B established with 2 streams (say) User A -----> User B re-INVITE Hold both streams User A <------ User B 200 OK with Hold SDP (2 way hold) User A -----> User B ACK and session is on hold now. NOW... User A -----> User B a re-INVITE w/o SDP Is this correct? If so, I have a feeling I agree with Brett. A response to a re-INVITE w/o SDP need not have a held SDP even if the UAS was earlier put on hold. REASON: On the list it had earlier been agreed that change of IP and/or port in ANY offer after the original INVITE is allowed. In case of responding to a re-INVITE w/o SDP, the offer is in the 200 OK to this re-INVITE. The UA SHOULD be allowed to send either of: 1. A hold SDP (like the previous 200 OK response that it sent) if it still wants A to be on hold. 2. A unhold SDP as this involves only a change of IP (or media stream) as it may now want User A to come off hold. What the UAS MUST NOT do is add a third stream (in addition to the 2 already accepted originally). It is free to put one or more of the 2 "originally in use streams" on/off hold. Comments please? Best regards, Siddharth. ================================= Siddharth Toshniwal Software Engineer Hughes Software Systems, Bangalore http://www.hssworld.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 11:28:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16389 for ; Thu, 4 Oct 2001 11:28:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22469; Thu, 4 Oct 2001 11:08:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22372 for ; Thu, 4 Oct 2001 11:08:46 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15658 for ; Thu, 4 Oct 2001 11:08:42 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f94F8Ag15698 for ; Thu, 4 Oct 2001 16:08:10 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Thu, 4 Oct 2001 16:07:54 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <42DWQWCN>; Thu, 4 Oct 2001 16:07:42 +0100 Message-ID: From: "Chris Hogg" To: "'stoshniwal@hss.hns.com'" Cc: "'Christer Holmberg'" , brett@broadsoft.com, sip@ietf.org Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 4 Oct 2001 15:34:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14CE1.BCB8BA20" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C14CE1.BCB8BA20 Content-Type: text/plain; charset="iso-8859-1" Hi everyone, Siddharth's scenario is very similar to the one I was discussing with the 3pcc. Amalgamating my scerario with the one described below, "A" in Siddharth's example is equivalent to my "controller"(C). Thus after the original INV/200/ACK transaction A may send a Re-INVITE to put B on hold. But A may then subsequently send a Re-INVITE with no SDP to B. B will reply with its' current SDP which may be hold or unhold SDP. The ACK from A may contain modified SDP (i.e. modified as a result of the controller talking to some other SIP UA) but I do not think it should add any new media streams. Comments? Regards Chris Chris Hogg Nortel Networks (UK). -----Original Message----- From: stoshniwal@hss.hns.com [mailto:stoshniwal@hss.hns.com] Sent: 04 October 2001 14:59 To: Hogg, Chris [MDN05:EP30:EXCH] Cc: 'Christer Holmberg'; brett@broadsoft.com; sip@ietf.org Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Hi everyone, Please find my comments below... >> I am not sure I agree on that. Isn't the 200 for a non-SDP >> re-INVITE supposed to return the current remote SDP, and if >> the call has been put on hold that should be a call-hold >> SDP (ie the SDP that was returned in the 200 for the call >> hold re-INVITE)? Just to confirm, the scenario we are talking about is User A <-----> User B established with 2 streams (say) User A -----> User B re-INVITE Hold both streams User A <------ User B 200 OK with Hold SDP (2 way hold) User A -----> User B ACK and session is on hold now. NOW... User A -----> User B a re-INVITE w/o SDP Is this correct? If so, I have a feeling I agree with Brett. A response to a re-INVITE w/o SDP need not have a held SDP even if the UAS was earlier put on hold. REASON: On the list it had earlier been agreed that change of IP and/or port in ANY offer after the original INVITE is allowed. In case of responding to a re-INVITE w/o SDP, the offer is in the 200 OK to this re-INVITE. The UA SHOULD be allowed to send either of: 1. A hold SDP (like the previous 200 OK response that it sent) if it still wants A to be on hold. 2. A unhold SDP as this involves only a change of IP (or media stream) as it may now want User A to come off hold. What the UAS MUST NOT do is add a third stream (in addition to the 2 already accepted originally). It is free to put one or more of the 2 "originally in use streams" on/off hold. Comments please? Best regards, Siddharth. ================================= Siddharth Toshniwal Software Engineer Hughes Software Systems, Bangalore http://www.hssworld.com ------_=_NextPart_001_01C14CE1.BCB8BA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx

Hi everyone,

Siddharth's scenario is very similar to the one I was = discussing with the 3pcc. Amalgamating my scerario with the one = described below, "A" in Siddharth's example is equivalent to = my "controller"(C).  Thus after the original INV/200/ACK = transaction A may send a Re-INVITE to put B on hold.  But A may = then subsequently send a Re-INVITE with no SDP to B.  B will reply = with its' current SDP which may be hold or unhold SDP.  The ACK = from A may contain modified SDP (i.e. modified as a result of the = controller talking to some other SIP UA) but I do not think it should = add any new media streams.

Comments?

Regards

Chris

Chris Hogg
Nortel Networks (UK).





-----Original Message-----
From: stoshniwal@hss.hns.com [mailto:stoshniwal@hss.hns.com= ]
Sent: 04 October 2001 14:59
To: Hogg, Chris [MDN05:EP30:EXCH]
Cc: 'Christer Holmberg'; brett@broadsoft.com; = sip@ietf.org
Subject: RE: [Sip] Open Issue #58: Rejected mid-call = SDP in 2xx





Hi everyone,

Please find my comments below...

>> I am not sure I agree on that. Isn't the 200 = for a non-SDP
>> re-INVITE supposed to return the current = remote SDP, and if
>> the call has been put on hold that should = be a call-hold
>> SDP (ie the SDP that was returned in the = 200 for the call
>> hold re-INVITE)?

Just to confirm, the scenario we are talking about = is

User A <-----> User B    = established with 2 streams (say)
User A  -----> User B    = re-INVITE Hold both streams
User A <------ User B    200 OK = with Hold SDP (2 way hold)
User A  -----> User B    ACK = and session is on hold now.

NOW...
User A  -----> User B    a = re-INVITE w/o SDP

Is this correct?


If so, I have a feeling I agree with Brett. A = response to a
re-INVITE w/o SDP need not have a held SDP even if = the UAS
was earlier put on hold.

REASON: On the list it had earlier been agreed that = change
of IP and/or port in ANY offer after the original = INVITE
is allowed. In case of responding to a re-INVITE w/o = SDP,
the offer is in the 200 OK to this re-INVITE. The UA = SHOULD
be allowed to send either of:

1. A hold SDP (like the previous 200 OK response that = it sent)
   if it still wants A to be on = hold.
2. A unhold SDP as this involves only a change of IP = (or
   media stream) as it may now want User A = to come off hold.

What the UAS MUST NOT do is add a third stream (in = addition
to the 2 already accepted originally). It is free to = put one
or more of the 2 "originally in use = streams" on/off hold.

Comments please?

Best regards,
Siddharth.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Siddharth Toshniwal
Software Engineer
Hughes Software Systems, Bangalore
http://www.hssworld.com



------_=_NextPart_001_01C14CE1.BCB8BA20-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 12:21:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18045 for ; Thu, 4 Oct 2001 12:21:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23602; Thu, 4 Oct 2001 11:49:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23536 for ; Thu, 4 Oct 2001 11:48:58 -0400 (EDT) Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16991 for ; Thu, 4 Oct 2001 11:48:54 -0400 (EDT) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmta01.netfr.alcatel.fr (frmta01.netfr.alcatel.fr [155.132.182.164]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id RAA22098; Thu, 4 Oct 2001 17:31:13 +0200 (MET DST) Received: by frmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256ADB.00553EC7 ; Thu, 4 Oct 2001 17:31:06 +0200 X-Lotus-FromDomain: ALCATEL To: "Chris Hogg" cc: "'stoshniwal@hss.hns.com'" , "'Christer Holmberg'" , brett@broadsoft.com, sip@ietf.org Message-ID: Date: Thu, 4 Oct 2001 17:30:57 +0200 Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=yV8yvmrQcKnjOVuEg28HywOjrNWVQ4WjySOYXWVb7oeJwdgUhUt0OIKl" Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --0__=yV8yvmrQcKnjOVuEg28HywOjrNWVQ4WjySOYXWVb7oeJwdgUhUt0OIKl Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, So, can I conclude saying that if there was no SDP in the Invite (or re-Invite), the SDP that can be sent by UA-A on an ACK message can only be a subset of the SDP received in the 200 message ? In other words, the UA sending the ACK (which is the same that sent the Invite w/o SDP) cannot improve the session description in this case. This way of reasonning seems to be very logic. If the UA-A is not happy with this SDP, can he still issue a CANCEL message, followed by a new re-Invite with modified SDP ? Is this the correct interpretation ? Best regards Juan Carlos "Chris Hogg" on 04/10/2001 16:34:56 To: "'stoshniwal@hss.hns.com'" cc: "'Christer Holmberg'" , brett@broadsoft.com, sip@ietf.org(bcc: Juan-Carlos ROJAS/FR/ALCATEL) Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Hi everyone, Siddharth's scenario is very similar to the one I was discussing with the 3pcc. Amalgamating my scerario with the one described below, "A" in Siddharth's example is equivalent to my "controller"(C). Thus after the original INV/200/ACK transaction A may send a Re-INVITE to put B on hold. But A may then subsequently send a Re-INVITE with no SDP to B. B will reply with its' current SDP which may be hold or unhold SDP. The ACK from A may contain modified SDP (i.e. modified as a result of the controller talking to some other SIP UA) but I do not think it should add any new media streams. Comments? Regards Chris Chris Hogg Nortel Networks (UK). -----Original Message----- From: stoshniwal@hss.hns.com [mailto:stoshniwal@hss.hns.com] Sent: 04 October 2001 14:59 To: Hogg, Chris [MDN05:EP30:EXCH] Cc: 'Christer Holmberg'; brett@broadsoft.com; sip@ietf.org Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Hi everyone, Please find my comments below... >> I am not sure I agree on that. Isn't the 200 for a non-SDP >> re-INVITE supposed to return the current remote SDP, and if >> the call has been put on hold that should be a call-hold >> SDP (ie the SDP that was returned in the 200 for the call >> hold re-INVITE)? Just to confirm, the scenario we are talking about is User A <-----> User B established with 2 streams (say) User A -----> User B re-INVITE Hold both streams User A <------ User B 200 OK with Hold SDP (2 way hold) User A -----> User B ACK and session is on hold now. NOW... User A -----> User B a re-INVITE w/o SDP Is this correct? If so, I have a feeling I agree with Brett. A response to a re-INVITE w/o SDP need not have a held SDP even if the UAS was earlier put on hold. REASON: On the list it had earlier been agreed that change of IP and/or port in ANY offer after the original INVITE is allowed. In case of responding to a re-INVITE w/o SDP, the offer is in the 200 OK to this re-INVITE. The UA SHOULD be allowed to send either of: 1. A hold SDP (like the previous 200 OK response that it sent) if it still wants A to be on hold. 2. A unhold SDP as this involves only a change of IP (or media stream) as it may now want User A to come off hold. What the UAS MUST NOT do is add a third stream (in addition to the 2 already accepted originally). It is free to put one or more of the 2 "originally in use streams" on/off hold. Comments please? Best regards, Siddharth. ================================= Siddharth Toshniwal Software Engineer Hughes Software Systems, Bangalore http://www.hssworld.com --0__=yV8yvmrQcKnjOVuEg28HywOjrNWVQ4WjySOYXWVb7oeJwdgUhUt0OIKl Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC44OSI+DQo8VElUTEU+UkU6IFtT aXBdIE9wZW4gSXNzdWUgIzU4OiBSZWplY3RlZCBtaWQtY2FsbCBTRFAgaW4gMnh4PC9USVRMRT4N CjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+SGkgZXZlcnlvbmUsPC9GT05UPg0K PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+U2lkZGhhcnRoJ3Mgc2NlbmFyaW8gaXMgdmVyeSBzaW1p bGFyIHRvIHRoZSBvbmUgSSB3YXMgZGlzY3Vzc2luZyB3aXRoIHRoZSAzcGNjLiBBbWFsZ2FtYXRp bmcgbXkgc2NlcmFyaW8gd2l0aCB0aGUgb25lIGRlc2NyaWJlZCBiZWxvdywgJnF1b3Q7QSZxdW90 OyBpbiBTaWRkaGFydGgncyBleGFtcGxlIGlzIGVxdWl2YWxlbnQgdG8gbXkgJnF1b3Q7Y29udHJv bGxlciZxdW90OyhDKS4mbmJzcDsgVGh1cyBhZnRlciB0aGUgb3JpZ2luYWwgSU5WLzIwMC9BQ0sg dHJhbnNhY3Rpb24gQSBtYXkgc2VuZCBhIFJlLUlOVklURSB0byBwdXQgQiBvbiBob2xkLiZuYnNw OyBCdXQgQSBtYXkgdGhlbiBzdWJzZXF1ZW50bHkgc2VuZCBhIFJlLUlOVklURSB3aXRoIG5vIFNE UCB0byBCLiZuYnNwOyBCIHdpbGwgcmVwbHkgd2l0aCBpdHMnIGN1cnJlbnQgU0RQIHdoaWNoIG1h eSBiZSBob2xkIG9yIHVuaG9sZCBTRFAuJm5ic3A7IFRoZSBBQ0sgZnJvbSBBIG1heSBjb250YWlu IG1vZGlmaWVkIFNEUCAoaS5lLiBtb2RpZmllZCBhcyBhIHJlc3VsdCBvZiB0aGUgY29udHJvbGxl ciB0YWxraW5nIHRvIHNvbWUgb3RoZXIgU0lQIFVBKSBidXQgSSBkbyBub3QgdGhpbmsgaXQgc2hv dWxkIGFkZCBhbnkgbmV3IG1lZGlhIHN0cmVhbXMuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0la RT0yPkNvbW1lbnRzPzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlJlZ2FyZHM8L0ZP TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5DaHJpczwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkNocmlzIEhvZ2c8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk5vcnRlbCBOZXR3 b3JrcyAoVUspLjwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZP TlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5Gcm9tOiBzdG9zaG5pd2FsQGhzcy5obnMuY29tIFs8QSBIUkVGPSJtYWlsdG86c3Rvc2hu aXdhbEBoc3MuaG5zLmNvbSI+bWFpbHRvOnN0b3Nobml3YWxAaHNzLmhucy5jb208L0E+XTwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+U2VudDogMDQgT2N0b2JlciAyMDAxIDE0OjU5PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5UbzogSG9nZywgQ2hyaXMgW01ETjA1OkVQMzA6RVhDSF08L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPkNjOiAnQ2hyaXN0ZXIgSG9sbWJlcmcnOyBicmV0dEBicm9hZHNv ZnQuY29tOyBzaXBAaWV0Zi5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6IFJF OiBbU2lwXSBPcGVuIElzc3VlICM1ODogUmVqZWN0ZWQgbWlkLWNhbGwgU0RQIGluIDJ4eDwvRk9O VD4NCjwvUD4NCjxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPkhpIGV2 ZXJ5b25lLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlBsZWFzZSBmaW5kIG15IGNv bW1lbnRzIGJlbG93Li4uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyZndDsg SSBhbSBub3Qgc3VyZSBJIGFncmVlIG9uIHRoYXQuIElzbid0IHRoZSAyMDAgZm9yIGEgbm9uLVNE UDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZndDsgcmUtSU5WSVRFIHN1cHBvc2VkIHRv IHJldHVybiB0aGUgY3VycmVudCByZW1vdGUgU0RQLCBhbmQgaWY8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsmZ3Q7IHRoZSBjYWxsIGhhcyBiZWVuIHB1dCBvbiBob2xkIHRoYXQgc2hvdWxk IGJlIGEgY2FsbC1ob2xkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jmd0OyBTRFAgKGll IHRoZSBTRFAgdGhhdCB3YXMgcmV0dXJuZWQgaW4gdGhlIDIwMCBmb3IgdGhlIGNhbGw8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmZ3Q7IGhvbGQgcmUtSU5WSVRFKT88L0ZPTlQ+DQo8L1A+ DQoNCjxQPjxGT05UIFNJWkU9Mj5KdXN0IHRvIGNvbmZpcm0sIHRoZSBzY2VuYXJpbyB3ZSBhcmUg dGFsa2luZyBhYm91dCBpczwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlVzZXIgQSAm bHQ7LS0tLS0mZ3Q7IFVzZXIgQiZuYnNwOyZuYnNwOyZuYnNwOyBlc3RhYmxpc2hlZCB3aXRoIDIg c3RyZWFtcyAoc2F5KTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+VXNlciBBJm5ic3A7IC0tLS0t Jmd0OyBVc2VyIEImbmJzcDsmbmJzcDsmbmJzcDsgcmUtSU5WSVRFIEhvbGQgYm90aCBzdHJlYW1z PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Vc2VyIEEgJmx0Oy0tLS0tLSBVc2VyIEImbmJzcDsm bmJzcDsmbmJzcDsgMjAwIE9LIHdpdGggSG9sZCBTRFAgKDIgd2F5IGhvbGQpPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj5Vc2VyIEEmbmJzcDsgLS0tLS0mZ3Q7IFVzZXIgQiZuYnNwOyZuYnNwOyZu YnNwOyBBQ0sgYW5kIHNlc3Npb24gaXMgb24gaG9sZCBub3cuPC9GT05UPg0KPC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTI+Tk9XLi4uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Vc2VyIEEmbmJzcDsg LS0tLS0mZ3Q7IFVzZXIgQiZuYnNwOyZuYnNwOyZuYnNwOyBhIHJlLUlOVklURSB3L28gU0RQPC9G T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SXMgdGhpcyBjb3JyZWN0PzwvRk9OVD4NCjwv UD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPklmIHNvLCBJIGhhdmUgYSBmZWVsaW5nIEkgYWdy ZWUgd2l0aCBCcmV0dC4gQSByZXNwb25zZSB0byBhPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5y ZS1JTlZJVEUgdy9vIFNEUCBuZWVkIG5vdCBoYXZlIGEgaGVsZCBTRFAgZXZlbiBpZiB0aGUgVUFT PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj53YXMgZWFybGllciBwdXQgb24gaG9sZC48L0ZPTlQ+ DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5SRUFTT046IE9uIHRoZSBsaXN0IGl0IGhhZCBlYXJs aWVyIGJlZW4gYWdyZWVkIHRoYXQgY2hhbmdlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5vZiBJ UCBhbmQvb3IgcG9ydCBpbiBBTlkgb2ZmZXIgYWZ0ZXIgdGhlIG9yaWdpbmFsIElOVklURTwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+aXMgYWxsb3dlZC4gSW4gY2FzZSBvZiByZXNwb25kaW5nIHRv IGEgcmUtSU5WSVRFIHcvbyBTRFAsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aGUgb2ZmZXIg aXMgaW4gdGhlIDIwMCBPSyB0byB0aGlzIHJlLUlOVklURS4gVGhlIFVBIFNIT1VMRDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+YmUgYWxsb3dlZCB0byBzZW5kIGVpdGhlciBvZjo8L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4xLiBBIGhvbGQgU0RQIChsaWtlIHRoZSBwcmV2aW91cyAy MDAgT0sgcmVzcG9uc2UgdGhhdCBpdCBzZW50KTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5i c3A7Jm5ic3A7IGlmIGl0IHN0aWxsIHdhbnRzIEEgdG8gYmUgb24gaG9sZC48L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPjIuIEEgdW5ob2xkIFNEUCBhcyB0aGlzIGludm9sdmVzIG9ubHkgYSBjaGFu Z2Ugb2YgSVAgKG9yPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgbWVkaWEg c3RyZWFtKSBhcyBpdCBtYXkgbm93IHdhbnQgVXNlciBBIHRvIGNvbWUgb2ZmIGhvbGQuPC9GT05U Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+V2hhdCB0aGUgVUFTIE1VU1QgTk9UIGRvIGlzIGFk ZCBhIHRoaXJkIHN0cmVhbSAoaW4gYWRkaXRpb248L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRv IHRoZSAyIGFscmVhZHkgYWNjZXB0ZWQgb3JpZ2luYWxseSkuIEl0IGlzIGZyZWUgdG8gcHV0IG9u ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+b3IgbW9yZSBvZiB0aGUgMiAmcXVvdDtvcmlnaW5h bGx5IGluIHVzZSBzdHJlYW1zJnF1b3Q7IG9uL29mZiBob2xkLjwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPkNvbW1lbnRzIHBsZWFzZT88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ WkU9Mj5CZXN0IHJlZ2FyZHMsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TaWRkaGFydGguPC9G T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TaWRkaGFydGggVG9zaG5pd2FsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5Tb2Z0d2FyZSBFbmdpbmVlcjwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+SHVnaGVzIFNvZnR3YXJlIFN5c3RlbXMsIEJhbmdhbG9yZTwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+PEEgSFJFRj0iaHR0cDovL3d3dy5oc3N3b3JsZC5jb20iIFRBUkdFVD0iX2JsYW5r Ij5odHRwOi8vd3d3Lmhzc3dvcmxkLmNvbTwvQT48L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQoN CjwvQk9EWT4NCjwvSFRNTD4= --0__=yV8yvmrQcKnjOVuEg28HywOjrNWVQ4WjySOYXWVb7oeJwdgUhUt0OIKl-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 15:23:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23402 for ; Thu, 4 Oct 2001 15:23:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00685; Thu, 4 Oct 2001 15:00:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00655 for ; Thu, 4 Oct 2001 15:00:54 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22479 for ; Thu, 4 Oct 2001 15:00:50 -0400 (EDT) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id f94ImRW15488; Thu, 4 Oct 2001 14:48:27 -0400 From: "Victor Paulsamy" To: "Chris Hogg" , Cc: "SIP" , , , "'Christer Holmberg'" , "Victor Paulsamy" Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 4 Oct 2001 11:48:53 -0700 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.2910.0) Importance: Normal In-Reply-To: <65256ADB.004CD6B5.00@sampark.hss.hns.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Just to confirm, the scenario we are talking about is > > User A <-----> User B established with 2 streams (say) > User A -----> User B re-INVITE Hold both streams > User A <------ User B 200 OK with Hold SDP (2 way hold) > User A -----> User B ACK and session is on hold now. > > NOW... > User A -----> User B a re-INVITE w/o SDP > > Is this correct? > > > If so, I have a feeling I agree with Brett. A response to a > re-INVITE w/o SDP need not have a held SDP even if the UAS > was earlier put on hold. > > REASON: On the list it had earlier been agreed that change > of IP and/or port in ANY offer after the original INVITE > is allowed. In case of responding to a re-INVITE w/o SDP, > the offer is in the 200 OK to this re-INVITE. The UA SHOULD > be allowed to send either of: > > 1. A hold SDP (like the previous 200 OK response that it sent) > if it still wants A to be on hold. > 2. A unhold SDP as this involves only a change of IP (or > media stream) as it may now want User A to come off hold. > > What the UAS MUST NOT do is add a third stream (in addition > to the 2 already accepted originally). It is free to put one > or more of the 2 "originally in use streams" on/off hold. > > Comments please? > In addition to the above two, the UAS can also send a third new SDP with addition/deletion/modification of new/old/old streams if it intends, as all characteristics of a session can be modified. Comments? Warm regards, --victor _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 15:58:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24026 for ; Thu, 4 Oct 2001 15:58:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02179; Thu, 4 Oct 2001 15:40:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02148 for ; Thu, 4 Oct 2001 15:40:15 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23733 for ; Thu, 4 Oct 2001 15:40:10 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f94Jdb000556; Thu, 4 Oct 2001 14:39:37 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f94Jdbo17334; Thu, 4 Oct 2001 14:39:37 -0500 (CDT) Received: from lmf.ericsson.se (rmt160227.am.ericsson.se [138.85.160.227]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA10923; Thu, 4 Oct 2001 14:39:33 -0500 (CDT) Message-ID: <3BBCBF40.3C094992@lmf.ericsson.se> Date: Thu, 04 Oct 2001 22:57:52 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: stoshniwal@hss.hns.com, sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.0067D2F9.00@sampark.hss.hns.com> <3BBBF18F.BFC292B1@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Christer, > It sounds pretty fine to me. There still is, however, the risk that the > UAS will not (or can not) accept the new SDP in the ACK. Why would the UAS not be able to accept the SDP in the ACK? The number of media streams is the same as the one is already in use. The set of codecs that will be used is the same as the current set. The only thing that can change is the IP address and the port number. Why is this change a big deal for the UAS? Regards, Gonzalo > Thanks for your comments! > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 17:20:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25136 for ; Thu, 4 Oct 2001 17:20:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04946; Thu, 4 Oct 2001 17:06:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04917 for ; Thu, 4 Oct 2001 17:06:01 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24982 for ; Thu, 4 Oct 2001 17:05:55 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f94L5M021375; Thu, 4 Oct 2001 16:05:22 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f94L5LE13346; Thu, 4 Oct 2001 16:05:21 -0500 (CDT) Received: from lmf.ericsson.se (rmt160227.am.ericsson.se [138.85.160.227]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA28223; Thu, 4 Oct 2001 16:05:18 -0500 (CDT) Message-ID: <3BBCD357.673E0FA6@lmf.ericsson.se> Date: Fri, 05 Oct 2001 00:23:35 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Medhavi Bhatia CC: sip@ietf.org Subject: Re: [Sip] sip based 3pcc References: <002001c148e3$cf9ec730$0100000a@deewana> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > Some simple advantages of the technique against the one specified in > Rosenberg/Peterson/Schulzrinne/Camarillo draft: One simple and big advantage of the Rosenberg/Peterson/Schulzrinne/Camarillo draft is that you do not need to use any SIP extension. That is, a controller can establish a session between the simplest SIP UAs that you can get (no REFER, no Replaces, etc...). Of course, if what you want to do is to establish a session between two particular UAs that support a number of fancy features, then you can do everything that those fancy features allow you to do... but I would not go so far to call this an advantage over the 3pcc approach. Regards, Gonzalo > > - Controller has the option of acting as a proxy or a back > to back user agent for the duration of the call after the REFER. > > - Controller does no have to manipulate any SDP, unless the > application desires it. > > - Does not rely on the usage of INVITE without SDP (a large number > of proxies and UAs have trouble handling it). > > - Does not require putting A or B on hold, which generally causes the > UA to put the peer back on hold. > > - Does not suffer from any potential timeout issues, or assume any > special behavior of the clients (some controllers use "flow 1" in the > sip-3pcc draft, which works best when B is some kind of automatic > device, like a media server). > > - Cannot cause an "infinite loop" of INVITEs (Some controllers tend to > use the "flow 2" in the sip-3pcc draft, which suffers from this > problem). > > The approach does use the SIP REFER method and the Replaces header: > > > A Controller B > | | | > | create callid1 | > | REFER callid1 | | > |<------------------| | > | | | > | 202 Accepted | | > |------------------>| | > | | | > |INVITE callid1 SDPA| | > |------------------>| | > | | | > | | INVITE SDP A | > | |----------------->| > | | | > | | 200 SDP B | > | |<-----------------| > | | | > | 200 SDP B | | > |<------------------| | > | | | > | ACK | | > |------------------>| | > | | | > | | ACK | > | |----------------->| > | | | > | | RTP | > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| > > In this scenario, the controller has no ongoing calls with A and B > in the beginning. It creates a local context for callid1. This context > MUST contain a SIP call id, and MAY contain from and to tags locally > generated at the controller. At this point the controller sends a > REFER > with the Replaces callid1 header to A. If A is interested in the call, > > it sends a 202 Accepted back to the controller. At this point the > controller starts a timer, "timer-callid1", on callid1 for TC seconds. > (TC is an application specific timer, which should at least take into > account the retransmissions from A. ~10*T2 seconds is probably a good > value). > When the INVITE arrives from A with the Replaces callid1 header, the > timer is cancelled, the INVITE is forwarded to B. At this point the > controller may act as a Back to Back user agent or a proxy for the > call duration, depending on the kind of application running on the > controller. The 200 OK from B arrives and is forwared to A. This way > the controller does not need to assume anything about what SDP will > be used for the call. > > 1. Controller creates SIP call leg 1 (Call id=12345%40192.168.118.3; > to-tag=12345;from-tag=5FFE-3994), and sends a REFER to > A: > > REFER sip:A@agentland SIP/2.0 > Via: SIP/2.0/UDP controller.nextone.net > To: > From: ;tag=193402342 > Call-ID: 898234234@controller.nextone.net > CSeq: 93809823 REFER > Refer-To: > to-tag=12345;from-tag=5FFE-3994> > Referred-By: > Contact: sip:B@controller.nextone.net > Content-Length: 0 > > Note the presence of the To tag, even though the INVITE is > being sent by A. The Controller may or may not put the To tag. > > 2. B sends a 202 Accepted to the Controller. > > 3. B sends an INVITE to the Controller > > INVITE > to-tag=12345;from-tag=5FFE-3994> SIP/2.0 > Via: SIP/2.0/UDP sip:A@agentland > From: A ;tag=3pcc > To: B > Call-ID: 31415@agentland > CSeq: 1 INVITE > Contact: A@agentland > > MID-call: > > The same mechanism can be used in the middle of a call. This is the > scenario when the controller already has a call up with A. The only > change in this case is that the REFER is sent on the existing call > leg. > The call flows in this case are similar to the call transfer call > flows given the sip-call-transfer draft. In this case A sends a NOTIFY > back to the controller, containing the status of the REFER, and the > controller disconnects the old call with A by sending a BYE to it. > > > A Controller B > | | | > | | | > | REFER callid1 | | > |<------------------| | > | | | > | 202 Accepted | | > |------------------>| | > | | | > |INVITE callid1 SDPA| | > |------------------>| | > | | | > | | INVITE SDP A | > | |----------------->| > | | | > | | 200 SDP B | > | |<-----------------| > | | | > | 200 SDP B | | > |<------------------| | > | | | > | ACK | | > |------------------>| | > | | | > | | ACK | > | |----------------->| > | NOTIFY (200 OK) | | > |------------------>| | > | | | > | 200 OK | | > |<------------------| | > | | | > | BYE | | > |<------------------| | > | | | > | | RTP | > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 17:35:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25328 for ; Thu, 4 Oct 2001 17:35:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05424; Thu, 4 Oct 2001 17:22:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05393 for ; Thu, 4 Oct 2001 17:22:13 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25163 for ; Thu, 4 Oct 2001 17:21:54 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f94LLpL15770; Thu, 4 Oct 2001 23:21:51 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f94LLol19527; Fri, 5 Oct 2001 00:21:50 +0300 (EET DST) Message-ID: <3BBCD2F0.A675DC45@lmf.ericsson.se> Date: Fri, 05 Oct 2001 00:21:52 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: stoshniwal@hss.hns.com, sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.0067D2F9.00@sampark.hss.hns.com> <3BBBF18F.BFC292B1@lmf.ericsson.se> <3BBCBF40.3C094992@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>It sounds pretty fine to me. There still is, however, the risk that the >>UAS will not (or can not) accept the new SDP in the ACK. > >Why would the UAS not be able to accept the SDP in the ACK? > >The number of media streams is the same as the one is already in use. >The set of codecs that will be used is the same as the current set. >The only thing that can change is the IP address and the port number. I thought that we agreed earlier that media streams can be replaced, ie we can replace a m= line with a new one, including a new codec etc - even a new media type. For example, the t.38 draft replaces an audio stream with an image (fax) stream. Or, isn't that allowd using the ACK SDP method? Also, even if the codec is not changed there may be some stream specific attributes (can't think of any right now, but they may be defined in future) added/changed to the ACK SDP, that were not included in the original SDP, which means the UAS can't send media according to those sets of attributes. Regards, Christer Holmberg Ericsson Finland > > Why is this change a big deal for the UAS? > > Regards, > > Gonzalo > > > Thanks for your comments! > > > > Christer Holmberg > > Ericsson Finland > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 17:50:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25601 for ; Thu, 4 Oct 2001 17:50:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06369; Thu, 4 Oct 2001 17:37:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06335 for ; Thu, 4 Oct 2001 17:37:51 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25394 for ; Thu, 4 Oct 2001 17:37:45 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f94LblY27638; Thu, 4 Oct 2001 16:37:47 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f94LblE27689; Thu, 4 Oct 2001 16:37:47 -0500 (CDT) Received: from lmf.ericsson.se (rmt160227.am.ericsson.se [138.85.160.227]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA06121; Thu, 4 Oct 2001 16:37:43 -0500 (CDT) Message-ID: <3BBCDAF0.36E04D75@lmf.ericsson.se> Date: Fri, 05 Oct 2001 00:56:00 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: stoshniwal@hss.hns.com, sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.0067D2F9.00@sampark.hss.hns.com> <3BBBF18F.BFC292B1@lmf.ericsson.se> <3BBCBF40.3C094992@lmf.ericsson.se> <3BBCD2F0.A675DC45@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer, Christer Holmberg wrote: > > Hi, > > >>It sounds pretty fine to me. There still is, however, the risk that the > >>UAS will not (or can not) accept the new SDP in the ACK. > > > >Why would the UAS not be able to accept the SDP in the ACK? > > > >The number of media streams is the same as the one is already in use. > >The set of codecs that will be used is the same as the current set. > >The only thing that can change is the IP address and the port number. > > I thought that we agreed earlier that media streams can be replaced, ie > we can replace a m= line with a new one, including a new codec etc - > even a new media type. We have agreed that upon reception of an empty re-INVITE, the only thing that can change in the SDP returned in the 200 OK is the port number and the IP address (and the version number in the o field). Therefore, the SDP sent in the ACK will be a valid answer for the offer made in the 200 OK. So, what you are saying is the same as asking: "what happens if a UAC sends an INVITE with SDP (offer) and then does not like the SDP in the 200 OK (answer)?". There are some rules that avoid this situation, namely the number of m lines has to be the same in the answer as in the offer, the set of codecs in the answer must have elements in common with the set in the offer, etc... Regards, Gonzalo > > For example, the t.38 draft replaces an audio stream with an image (fax) > stream. > > Or, isn't that allowd using the ACK SDP method? > > Also, even if the codec is not changed there may be some stream specific > attributes (can't think of any right now, but they may be defined in > future) added/changed to the ACK SDP, that were not included in the > original SDP, which means the UAS can't send media according to those > sets of attributes. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Why is this change a big deal for the UAS? > > > > Regards, > > > > Gonzalo > > > > > Thanks for your comments! > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 18:02:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25754 for ; Thu, 4 Oct 2001 18:02:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06676; Thu, 4 Oct 2001 17:50:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06644 for ; Thu, 4 Oct 2001 17:50:44 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25617 for ; Thu, 4 Oct 2001 17:50:34 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f94LoYC13867; Thu, 4 Oct 2001 23:50:34 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f94LoXl20056; Fri, 5 Oct 2001 00:50:33 +0300 (EET DST) Message-ID: <3BBCD9AA.940E514A@lmf.ericsson.se> Date: Fri, 05 Oct 2001 00:50:34 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: stoshniwal@hss.hns.com, sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.0067D2F9.00@sampark.hss.hns.com> <3BBBF18F.BFC292B1@lmf.ericsson.se> <3BBCBF40.3C094992@lmf.ericsson.se> <3BBCD2F0.A675DC45@lmf.ericsson.se> <3BBCDAF0.36E04D75@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>I thought that we agreed earlier that media streams can be replaced, ie >>we can replace a m= line with a new one, including a new codec etc - >>even a new media type. >We have agreed that upon reception of an empty re-INVITE, the only thing >that can change in the SDP returned in the 200 OK is the port number and >the IP address (and the version number in the o field). Therefore, the >SDP sent in the ACK will be a valid answer for the offer made in the 200 >OK. > >So, what you are saying is the same as asking: "what happens if a UAC >sends an INVITE with SDP (offer) and then does not like the SDP in the >200 OK (answer)?". > >There are some rules that avoid this situation, namely the number of m >lines has to be the same in the answer as in the offer, Yes, I think we all agree on that. >the set of codecs in the answer must have elements in common with the set in the >offer, etc... So, when we replace a stream with another that new stream must have the SAME codec, the SAME attributes, and the SAME media type, and the ONLY thing we are allowed to change is the IP address and/or the port? Or, once again: are we allowed to change whatever information for a stream in a re-INVITE SDP, but only the IP address and/or port in an ACK SDP? If that is NOT the case, the propsal of using an attribute for the call hold will not work, since we change an attribute for an existing stream.... And, the t.38 fax scenarios won't work, since we replace an audio type stream with an image type stream... Regards, Christer Holmberg Ericsson Finland > > Regards, > > Gonzalo > > > > > For example, the t.38 draft replaces an audio stream with an image (fax) > > stream. > > > > Or, isn't that allowd using the ACK SDP method? > > > > Also, even if the codec is not changed there may be some stream specific > > attributes (can't think of any right now, but they may be defined in > > future) added/changed to the ACK SDP, that were not included in the > > original SDP, which means the UAS can't send media according to those > > sets of attributes. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Why is this change a big deal for the UAS? > > > > > > Regards, > > > > > > Gonzalo > > > > > > > Thanks for your comments! > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > New York, NY 10027 > > > USA Gonzalo.Camarillo@ericsson.com > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 18:14:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25845 for ; Thu, 4 Oct 2001 18:14:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06871; Thu, 4 Oct 2001 17:59:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06842 for ; Thu, 4 Oct 2001 17:59:43 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25703 for ; Thu, 4 Oct 2001 17:59:36 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f94LxbC18761; Thu, 4 Oct 2001 23:59:37 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f94Lxal20150; Fri, 5 Oct 2001 00:59:36 +0300 (EET DST) Message-ID: <3BBCDBCA.812344BD@lmf.ericsson.se> Date: Fri, 05 Oct 2001 00:59:38 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: stoshniwal@hss.hns.com CC: Chris Hogg , brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADB.004CD6B5.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>>I am not sure I agree on that. Isn't the 200 for a non-SDP >>>re-INVITE supposed to return the current remote SDP, and if >>>the call has been put on hold that should be a call-hold >>>SDP (ie the SDP that was returned in the 200 for the call >>>hold re-INVITE)? > >Just to confirm, the scenario we are talking about is > >User A <-----> User B established with 2 streams (say) >User A -----> User B re-INVITE Hold both streams >User A <------ User B 200 OK with Hold SDP (2 way hold) >User A -----> User B ACK and session is on hold now. > >NOW... >User A -----> User B a re-INVITE w/o SDP > >Is this correct? > >If so, I have a feeling I agree with Brett. A response to a >re-INVITE w/o SDP need not have a held SDP even if the UAS >was earlier put on hold. > >REASON: On the list it had earlier been agreed that change >of IP and/or port in ANY offer after the original INVITE >is allowed. In case of responding to a re-INVITE w/o SDP, >the offer is in the 200 OK to this re-INVITE. The UA SHOULD >be allowed to send either of: > >1. A hold SDP (like the previous 200 OK response that it sent) > if it still wants A to be on hold. >2. A unhold SDP as this involves only a change of IP (or > media stream) as it may now want User A to come off hold. What if we use an SDP attribute, and not the IP address, for the call hold? In that case this would not work, since the current attribute value is "on-hold" (or whatever we will use) and the UAS in not allowed to change that in the 200. I have no problem with what has been agreed, ie that the IP address and/or port can change at any time, but I think that changing from hold to non-hold is a change of STATE (even if SIP currently impelments it using the 0.0.0.0 IP address). >What the UAS MUST NOT do is add a third stream (in addition >to the 2 already accepted originally). It is free to put one >or more of the 2 "originally in use streams" on/off hold. What if the UAC - for any reason - only wants the remote SDP, but it does NOT want the re-INVITE to un-hold the session? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 19:40:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26357 for ; Thu, 4 Oct 2001 19:40:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09096; Thu, 4 Oct 2001 19:24:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09064 for ; Thu, 4 Oct 2001 19:24:24 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26260 for ; Thu, 4 Oct 2001 19:24:21 -0400 (EDT) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id f94NO9W16919; Thu, 4 Oct 2001 19:24:09 -0400 From: "Victor Paulsamy" To: , "Chris Hogg" Cc: "'Christer Holmberg'" , , , "Victor Paulsamy" Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 4 Oct 2001 16:24:35 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <65256ADB.004CD6B5.00@sampark.hss.hns.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > REASON: On the list it had earlier been agreed that change > of IP and/or port in ANY offer after the original INVITE > is allowed. In case of responding to a re-INVITE w/o SDP, > the offer is in the 200 OK to this re-INVITE. The UA SHOULD > be allowed to send either of: > > 1. A hold SDP (like the previous 200 OK response that it sent) > if it still wants A to be on hold. > 2. A unhold SDP as this involves only a change of IP (or > media stream) as it may now want User A to come off hold. > > What the UAS MUST NOT do is add a third stream (in addition > to the 2 already accepted originally). It is free to put one > or more of the 2 "originally in use streams" on/off hold. > > Comments please? > Why the UAS MUST NOT "add" a new stream? Thanks. Warm regards, --victor _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 21:07:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27037 for ; Thu, 4 Oct 2001 21:07:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11014; Thu, 4 Oct 2001 20:46:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10983 for ; Thu, 4 Oct 2001 20:46:42 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26783 for ; Thu, 4 Oct 2001 20:46:38 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f950kbp54100; Thu, 4 Oct 2001 20:46:37 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Victor Paulsamy'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 4 Oct 2001 20:46:51 -0400 Message-ID: <002a01c14d37$39381000$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Why the UAS MUST NOT "add" a new stream? It is tempting since that is what basically happens for invite-without-sdp; the UAS adds all it desires. However it serves no real purpose within reinvite-without-sdp. Some action on the "UAS" would trigger the desire to add the extra media stream. And if this is the case, it is capable to trigger its own reinvite-with-sdp instead of waiting for reinvite-without-sdp. Ultimately I'm indifferent on adding streams since the UAS can add it and the UAC can delete it. I think that some objected to the poor communication as to why the stream was not accepted. This is also a problem for the first invite case. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 22:00:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28487 for ; Thu, 4 Oct 2001 22:00:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12200; Thu, 4 Oct 2001 21:42:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12104 for ; Thu, 4 Oct 2001 21:42:10 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28257 for ; Thu, 4 Oct 2001 21:42:06 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f951fek25150; Thu, 4 Oct 2001 18:41:40 -0700 (PDT) Received: from cisco.com (sarvi-w2k1-1.cisco.com [128.107.138.201]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAP03132 (AUTH sarvi); Thu, 4 Oct 2001 18:41:23 -0700 (PDT) Message-ID: <3BBD0E54.4EE89439@cisco.com> Date: Thu, 04 Oct 2001 18:35:17 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------F6955B95499BEFA212DF0400" Subject: [Sip] SIP INFO method - Any reason it MUST BE stateless. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------F6955B95499BEFA212DF0400 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Today according to the INFO RFC, the SIP INFO method is stateless, i.e if server A issues an INFO method on an existing SIP session with another server B, and the method body contains some data(lets say a proprietary command, like READFILE abcd.jpg). Server B has to either 1. come back with all the data read in the body of the 200 OK response for the INFO method(it may be large or time consuming) 2. do a 200 OK reponse for the INFO method with an acknowldgement for the READ command and may be an initial chunk. The server B may have to send each subsequent chunk of data on a separate INFO method to A, for which server A has to respond with a 200 OK. This could be highly inefficient. I would have prefered to be able to send one INFO method and get back multiple 18x OK methods carrying the intermediate chunks of data and have the final chunk carry the 200 OK. Is there a specific reason why the the INFO method MUST BE stateless. Because, it looks like the INFO method could be used to get information that may have to come as multiple chunks. thanks, Sarvi --------------F6955B95499BEFA212DF0400 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Saravanan x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Center adr:;;170 W Tasman Drive;San Jose;CA;95134;USA version:2.1 email;internet:sarvi@cisco.com title:Software Engineer fn:Saravanan Shanmugham end:vcard --------------F6955B95499BEFA212DF0400-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 22:00:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28505 for ; Thu, 4 Oct 2001 22:00:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12267; Thu, 4 Oct 2001 21:48:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12236 for ; Thu, 4 Oct 2001 21:48:31 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28292 for ; Thu, 4 Oct 2001 21:48:27 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f951mSe76721; Thu, 4 Oct 2001 21:48:29 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Victor Paulsamy'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 4 Oct 2001 21:48:42 -0400 Message-ID: <002d01c14d3f$dd530b10$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > > Why the UAS MUST NOT "add" a new stream? > > > > It is tempting since that is what basically > > happens for invite-without-sdp; the UAS adds > > all it desires. However it serves no real > > purpose within reinvite-without-sdp. > > Some action on the "UAS" would trigger the > > desire to add the extra media stream. > > And if this is the case, it is capable to > > trigger its own reinvite-with-sdp instead > > of waiting for reinvite-without-sdp. > > > When the UAS is thinking of sending a > re-INVITE to add a stream, there comes > a re-INVITE from the UAC without SDP. Can the > UAS not seize the opportunity to add a stream. I find no harm since it makes it consistent with invite-without-sdp. However if the only benefit is the saving of 3 messages, it was deemed not important enough. Otherwise we could have allowed the 200 SDP to contain an answer and offer portion. > I'm not seeing the point why it shouldn't be > added when *all* characteristics of the > session can be changed. Actually *all* characteristics shouldn't be changed. This was the reason for the open issue. After receiving a reinvite-without-sdp, the UAS should attempt to not modify the SDP's existing media in such a way that would potentially cause the UAC to have to hold it, delete it, or release the call. Thus most of the time it should return the previous SDP. Devices that answer hold to holds should not return the previous SDP unless it desires to keep the call on hold. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 22:03:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28547 for ; Thu, 4 Oct 2001 22:03:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11520; Thu, 4 Oct 2001 21:06:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11489 for ; Thu, 4 Oct 2001 21:06:32 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27012 for ; Thu, 4 Oct 2001 21:06:28 -0400 (EDT) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id f9516TW03913; Thu, 4 Oct 2001 21:06:29 -0400 From: "Victor Paulsamy" To: Cc: , "Victor Paulsamy" Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 4 Oct 2001 18:06:55 -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: <002a01c14d37$39381000$2b01a8c0@broadsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Brett, Thanks for your comment. > > Why the UAS MUST NOT "add" a new stream? > > It is tempting since that is what basically > happens for invite-without-sdp; the UAS adds > all it desires. However it serves no real > purpose within reinvite-without-sdp. > Some action on the "UAS" would trigger the > desire to add the extra media stream. > And if this is the case, it is capable to > trigger its own reinvite-with-sdp instead > of waiting for reinvite-without-sdp. > When the UAS is thinking of sending a re-INVITE to add a stream, there comes a re-INVITE from the UAC without SDP. Can the UAS not seize the opportunity to add a stream. I'm not seeing the point why it shouldn't be added when *all* characteristics of the session can be changed. > Ultimately I'm indifferent on adding streams > since the UAS can add it and the UAC can > delete it. I think that some objected to > the poor communication as to why the stream > was not accepted. This is also a problem > for the first invite case. > Exactly. Warm regards, --victor _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 4 22:14:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28624 for ; Thu, 4 Oct 2001 22:14:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13151; Thu, 4 Oct 2001 22:02:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13120 for ; Thu, 4 Oct 2001 22:02:45 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28544 for ; Thu, 4 Oct 2001 22:02:41 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f9522gT78735; Thu, 4 Oct 2001 22:02:42 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Christer Holmberg'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 4 Oct 2001 22:02:55 -0400 Message-ID: <002e01c14d41$d9ec4e80$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BBCDBCA.812344BD@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > What if we use an SDP attribute, and not > the IP address, for the call > hold? In that case this would not work, > since the current attribute > value is "on-hold" (or whatever we will use) > and the UAS in not allowed > to change that in the 200. That particular attribute should be allowed to change. I don't recall anyone responding negatively to the comment when I mentioned it previously on the thread. http://www1.ietf.org/mail-archive/working-groups/sip/current/msg01161.html > I have no problem with what has been > agreed, ie that the IP address > and/or port can change at any time, > but I think that changing from hold > to non-hold is a change of STATE > (even if SIP currently impelments it > using the 0.0.0.0 IP address). Correct. And the UAS decides if it wants to keep the session on hold or allow it to be pulled off hold. > What if the UAC - for any reason - only > wants the remote SDP, but it does NOT want > the re-INVITE to un-hold the session? It sends a reinvite-with-sdp. The UAS can keep the session on hold if it desires. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 00:33:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01201 for ; Fri, 5 Oct 2001 00:33:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15622; Fri, 5 Oct 2001 00:11:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15588 for ; Fri, 5 Oct 2001 00:11:05 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00834 for ; Fri, 5 Oct 2001 00:10:58 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f954Agu11854; Thu, 4 Oct 2001 21:10:42 -0700 (PDT) Received: from cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAQ00332 (AUTH sarvi); Thu, 4 Oct 2001 21:10:11 -0700 (PDT) Message-ID: <3BBD3135.C24D3240@cisco.com> Date: Thu, 04 Oct 2001 21:04:05 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] SIP INFO method - Any reason it MUST BE stateless. References: <003101c14d4f$e0a3a260$2b01a8c0@broadsoft.com> Content-Type: multipart/mixed; boundary="------------EE95F0AE600CA5BB3A029124" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------EE95F0AE600CA5BB3A029124 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brett Tate wrote: > > Today according to the INFO RFC, the SIP INFO method is stateless, > > i.e if server A issues an INFO method on an existing SIP session with > > another server B, and the method body contains some data(lets say a > > proprietary command, like READFILE abcd.jpg). Server B has to either > > 1. come back with all the data read in the body of the 200 OK > > response for the INFO method(it may be large or time consuming) > > 2. do a 200 OK reponse for the INFO method with an acknowldgement > > for the READ command and may be an initial chunk. The server > > B may have > > to send each subsequent chunk of data on a separate INFO method to A, > > for which server A has to respond with a 200 OK. This could be highly > > inefficient. > > > > I would have prefered to be able to send one INFO method and get back > > multiple 18x OK methods carrying the intermediate chunks of data and > > have the final chunk carry the 200 OK. > > Should work if using 100rel extention, however I'm > sure some people might be opposed to using the INFO > for this or for anything. This is good news. We would like to use the INFO method for peer to peer communication of applications on either end of the SIP session. > > > > Is there a specific reason why the the INFO > > method MUST BE stateless. > > It isn't stateless. The specification mentions > that it MUST NOT effect call state or the state > of related sessions. > Agreed. Our requirement is to conduct a request/response conversation between two application level entities sitting above the SIP stack on either side. We do not expect any change in call or session state. Thanks, Sarvi > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------EE95F0AE600CA5BB3A029124 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Saravanan x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Center adr:;;170 W Tasman Drive;San Jose;CA;95134;USA version:2.1 email;internet:sarvi@cisco.com title:Software Engineer fn:Saravanan Shanmugham end:vcard --------------EE95F0AE600CA5BB3A029124-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 00:43:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01256 for ; Fri, 5 Oct 2001 00:43:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14841; Thu, 4 Oct 2001 23:43:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14811 for ; Thu, 4 Oct 2001 23:43:07 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00622 for ; Thu, 4 Oct 2001 23:43:02 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f953h6Y92709; Thu, 4 Oct 2001 23:43:06 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] SIP INFO method - Any reason it MUST BE stateless. Date: Thu, 4 Oct 2001 23:43:19 -0400 Message-ID: <003101c14d4f$e0a3a260$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BBD0E54.4EE89439@cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Today according to the INFO RFC, the SIP INFO method is stateless, > i.e if server A issues an INFO method on an existing SIP session with > another server B, and the method body contains some data(lets say a > proprietary command, like READFILE abcd.jpg). Server B has to either > 1. come back with all the data read in the body of the 200 OK > response for the INFO method(it may be large or time consuming) > 2. do a 200 OK reponse for the INFO method with an acknowldgement > for the READ command and may be an initial chunk. The server > B may have > to send each subsequent chunk of data on a separate INFO method to A, > for which server A has to respond with a 200 OK. This could be highly > inefficient. > > I would have prefered to be able to send one INFO method and get back > multiple 18x OK methods carrying the intermediate chunks of data and > have the final chunk carry the 200 OK. Should work if using 100rel extention, however I'm sure some people might be opposed to using the INFO for this or for anything. > Is there a specific reason why the the INFO > method MUST BE stateless. It isn't stateless. The specification mentions that it MUST NOT effect call state or the state of related sessions. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 01:14:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01990 for ; Fri, 5 Oct 2001 01:14:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16698; Fri, 5 Oct 2001 00:53:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16669 for ; Fri, 5 Oct 2001 00:53:19 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01351 for ; Fri, 5 Oct 2001 00:53:16 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f954rGC13879; Fri, 5 Oct 2001 06:53:16 +0200 (MEST) Received: from lmf.ericsson.se (lmf03754pc.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f954rGl28550; Fri, 5 Oct 2001 07:53:16 +0300 (EET DST) Message-ID: <3BBD3CBA.EA099884@lmf.ericsson.se> Date: Fri, 05 Oct 2001 07:53:14 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <002e01c14d41$d9ec4e80$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>What if we use an SDP attribute, and not >>the IP address, for the call >>hold? In that case this would not work, >>since the current attribute >>value is "on-hold" (or whatever we will use) >>and the UAS in not allowed >>to change that in the 200. > >That particular attribute should be allowed >to change. I don't recall anyone responding >negatively to the comment when I mentioned it >previously on the thread. "That particular attribute"... I was afraid you were going to say that :) In future we may have (or maybe there already exist) other similar attributes, for other services, and then we suddenly may have to allow those particular attributes to change too... For example, someone may come up with some SECURITY related attributes, some CHARGING related attributes, some other MEDIA related attributes (echo canceller, silence supression, etc etc etc), some who-knows-what attributes, that we must be able to change during the session... >>I have no problem with what has been >>agreed, ie that the IP address >>and/or port can change at any time, >>but I think that changing from hold >>to non-hold is a change of STATE >>(even if SIP currently impelments it >>using the 0.0.0.0 IP address). >Correct. And the UAS decides if it wants >to keep the session on hold or allow it to >be pulled off hold. I think that if the UAS wants to pull off the hold, it should send an un-hold re-INVITE. >>What if the UAC - for any reason - only >>wants the remote SDP, but it does NOT want >>the re-INVITE to un-hold the session? >It sends a reinvite-with-sdp. The UAS can >keep the session on hold if it desires. ...or it can return a un-hold SDP in this case too. Thanks for your comments! Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 01:17:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02179 for ; Fri, 5 Oct 2001 01:17:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17187; Fri, 5 Oct 2001 01:04:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17156 for ; Fri, 5 Oct 2001 01:04:12 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01445 for ; Fri, 5 Oct 2001 01:04:09 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f95549L08648; Fri, 5 Oct 2001 07:04:09 +0200 (MEST) Received: from lmf.ericsson.se (lmf03754pc.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f95549l28770; Fri, 5 Oct 2001 08:04:09 +0300 (EET DST) Message-ID: <3BBD3F47.B17A734F@lmf.ericsson.se> Date: Fri, 05 Oct 2001 08:04:07 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sarvi Shanmugham CC: brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] SIP INFO method - Any reason it MUST BE stateless. References: <003101c14d4f$e0a3a260$2b01a8c0@broadsoft.com> <3BBD3135.C24D3240@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Sarvi, In general, I think the issue is related to a similar one we had for Megaco, where it was discussed how a response could be split into multiple "provisional" responses if it couldn't fit into a single UDP package. Like Brett said, using INFO like this may not be correct, but I guess that depends on exactly what you want to do. Another way would be for the UAS to simply return 200 to the INFO, and then send an INFO itself with the required data. Then, if you can't fit all data into a single INFO I guess you could split the data into multiple INFOs, using some attribute to indicate to the receiver when all data has been sent. No, I am NOT talking about any "INFO overlapping", but completely separate INFO transactions :) Regards, Christer Holmberg Ericsson Finland Sarvi Shanmugham wrote: > > Brett Tate wrote: > > > > Today according to the INFO RFC, the SIP INFO method is stateless, > > > i.e if server A issues an INFO method on an existing SIP session with > > > another server B, and the method body contains some data(lets say a > > > proprietary command, like READFILE abcd.jpg). Server B has to either > > > 1. come back with all the data read in the body of the 200 OK > > > response for the INFO method(it may be large or time consuming) > > > 2. do a 200 OK reponse for the INFO method with an acknowldgement > > > for the READ command and may be an initial chunk. The server > > > B may have > > > to send each subsequent chunk of data on a separate INFO method to A, > > > for which server A has to respond with a 200 OK. This could be highly > > > inefficient. > > > > > > I would have prefered to be able to send one INFO method and get back > > > multiple 18x OK methods carrying the intermediate chunks of data and > > > have the final chunk carry the 200 OK. > > > > Should work if using 100rel extention, however I'm > > sure some people might be opposed to using the INFO > > for this or for anything. > > This is good news. > We would like to use the INFO method for peer to peer communication of > applications on either end of the SIP session. > > > > > > > > Is there a specific reason why the the INFO > > > method MUST BE stateless. > > > > It isn't stateless. The specification mentions > > that it MUST NOT effect call state or the state > > of related sessions. > > > > Agreed. > Our requirement is to conduct a request/response conversation between two > application level entities sitting above the SIP stack on either side. > We do not expect any change in call or session state. > > Thanks, > Sarvi > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 01:25:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02629 for ; Fri, 5 Oct 2001 01:25:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15869; Fri, 5 Oct 2001 00:27:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15838 for ; Fri, 5 Oct 2001 00:27:37 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01131 for ; Fri, 5 Oct 2001 00:27:35 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f954OvC27519; Thu, 4 Oct 2001 21:24:57 -0700 (PDT) Received: from cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAQ00559 (AUTH sarvi); Thu, 4 Oct 2001 21:26:45 -0700 (PDT) Message-ID: <3BBD3517.4D7223F2@cisco.com> Date: Thu, 04 Oct 2001 21:20:39 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-cc-transfer-05 References: <9BF66EBF6BEFD942915B4D4D45C051F338E61D.13168@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------280CB5909750897A0F6C5F98" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------280CB5909750897A0F6C5F98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert, Could you please refer me to the thread that discusses this. What is the reasoning for not allowing provisional responses to the REFER method. Seems to me, that would be the cleaner way of doing this than a one time REGISTER with a NOTIFY option. As with this method, the Transferor cannot get intermediate status of how the transfer is going. The transferor application may want do certain things based on that status. One example on a TELE-to-SIP gateway, would be a choice of when the TELE side should be disconnected or dropped. The application might want to keep the telephony leg active till, 1. the Transferee ACKs the REFER(which I believe doesn't necessarily mean the phone is ringing) 2. the Transferee says the destination is ringing(may be he wants to reconnect if the destination comes back as a ring no-answer. 3. the Transferee says the destination is connected. Thanks, Sarvi Robert Sparks wrote: > If only we could... > > No. Non-INVITE transactions do not pend. They must > complete immediately. If you've been following the > open issues threads, you'll have seen the suggestion > to kill off provisional responses (other than a 100 > Trying to quench retransmissions) to non-INVITES. > > This feature of the non-INVITE transaction model is > why we have the implicit subscribe and the separate > NOTIFY instead of just waiting for the triggered > action to complete before sending the final response > to the REFER (on a historical note, that was the original > proposal of over a year ago). > > RjS > > > -----Original Message----- > > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > > Sent: Tuesday, September 25, 2001 11:57 AM > > To: sip@ietf.org > > Subject: [Sip] draft-ietf-sip-cc-transfer-05 > > > > > > > > I have a question/concern in the blind transfer case. > > > > As per the current spec, > > The TRANSFEREE responds with a Ack 202 to the REFER method, before > > the attempt to the Transfer target is initiated. > > > > The next possible message from the Transferee to the Transferor is > > NOTIFY(200 OK) and this is when the Transfer target > > accepts(picks up the > > phone). > > > > In a blind transfer, where I want to release the > > Transferor, Ack202 > > "may be" premature, and NOTIFY(200 OK) may be too late. > > > > Can the Transferee gateway, send an intermediate NOTIFY(180 OK) > > when the transfer target is "ringing". This could be a more reliable > > place to release the Transferee's line, than Ack 202 > > > > Any thoughts, > > Sarvi > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------280CB5909750897A0F6C5F98 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Saravanan x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Center adr:;;170 W Tasman Drive;San Jose;CA;95134;USA version:2.1 email;internet:sarvi@cisco.com title:Software Engineer fn:Saravanan Shanmugham end:vcard --------------280CB5909750897A0F6C5F98-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 03:00:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16127 for ; Fri, 5 Oct 2001 03:00:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26127; Fri, 5 Oct 2001 02:39:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26095 for ; Fri, 5 Oct 2001 02:39:41 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14881 for ; Fri, 5 Oct 2001 02:39:39 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f956dOu00014; Thu, 4 Oct 2001 23:39:24 -0700 (PDT) Received: from cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAQ02044 (AUTH sarvi); Thu, 4 Oct 2001 23:38:54 -0700 (PDT) Message-ID: <3BBD5410.FB6EB7EA@cisco.com> Date: Thu, 04 Oct 2001 23:32:48 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] SIP INFO method - Any reason it MUST BE stateless. References: <003101c14d4f$e0a3a260$2b01a8c0@broadsoft.com> <3BBD3135.C24D3240@cisco.com> <3BBD3F47.B17A734F@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------E41044DD23DDACF2E32364D4" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------E41044DD23DDACF2E32364D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Christer, Christer Holmberg wrote: > Hi Sarvi, > > In general, I think the issue is related to a similar one we had for > Megaco, where it was discussed how a response could be split into > multiple "provisional" responses if it couldn't fit into a single UDP > package. > > Like Brett said, using INFO like this may not be correct, but I guess Like you have pointed out below using a separate INFO methods for the each chunk of response data is definitley a possibility. But, as you might already notice, it is not a very efficient mechanism, compared to doing it with provisional responses. it uses way more messages between the two endpoints to accomplish this. So what I am trying to understand is, if there is some sort pitfall or problem that people see in, either now or in the future permitting provisional responses in the INFO method as part of SIP. Regards, Sarvi. > > that depends on exactly what you want to do. Another way would be for > the UAS to simply return 200 to the INFO, and then send an INFO itself > with the required data. Then, if you can't fit all data into a single > INFO I guess you could split the data into multiple INFOs, using some > attribute to indicate to the receiver when all data has been sent. > > No, I am NOT talking about any "INFO overlapping", but completely > separate INFO transactions :) > > Regards, > > Christer Holmberg > Ericsson Finland > > Sarvi Shanmugham wrote: > > > > Brett Tate wrote: > > > > > > Today according to the INFO RFC, the SIP INFO method is stateless, > > > > i.e if server A issues an INFO method on an existing SIP session with > > > > another server B, and the method body contains some data(lets say a > > > > proprietary command, like READFILE abcd.jpg). Server B has to either > > > > 1. come back with all the data read in the body of the 200 OK > > > > response for the INFO method(it may be large or time consuming) > > > > 2. do a 200 OK reponse for the INFO method with an acknowldgement > > > > for the READ command and may be an initial chunk. The server > > > > B may have > > > > to send each subsequent chunk of data on a separate INFO method to A, > > > > for which server A has to respond with a 200 OK. This could be highly > > > > inefficient. > > > > > > > > I would have prefered to be able to send one INFO method and get back > > > > multiple 18x OK methods carrying the intermediate chunks of data and > > > > have the final chunk carry the 200 OK. > > > > > > Should work if using 100rel extention, however I'm > > > sure some people might be opposed to using the INFO > > > for this or for anything. > > > > This is good news. > > We would like to use the INFO method for peer to peer communication of > > applications on either end of the SIP session. > > > > > > > > > > > > Is there a specific reason why the the INFO > > > > method MUST BE stateless. > > > > > > It isn't stateless. The specification mentions > > > that it MUST NOT effect call state or the state > > > of related sessions. > > > > > > > Agreed. > > Our requirement is to conduct a request/response conversation between two > > application level entities sitting above the SIP stack on either side. > > We do not expect any change in call or session state. > > > > Thanks, > > Sarvi > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip --------------E41044DD23DDACF2E32364D4 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Saravanan x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Center adr:;;170 W Tasman Drive;San Jose;CA;95134;USA version:2.1 email;internet:sarvi@cisco.com title:Software Engineer fn:Saravanan Shanmugham end:vcard --------------E41044DD23DDACF2E32364D4-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 03:25:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16707 for ; Fri, 5 Oct 2001 03:25:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27031; Fri, 5 Oct 2001 03:09:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27000 for ; Fri, 5 Oct 2001 03:09:51 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16628 for ; Fri, 5 Oct 2001 03:09:46 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9579kL15034; Fri, 5 Oct 2001 09:09:46 +0200 (MEST) Received: from lmf.ericsson.se (lmf03754pc.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9579jL03573; Fri, 5 Oct 2001 10:09:45 +0300 (EET DST) Message-ID: <3BBD5CB7.2A47C256@lmf.ericsson.se> Date: Fri, 05 Oct 2001 10:09:43 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sarvi Shanmugham CC: brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] SIP INFO method - Any reason it MUST BE stateless. References: <003101c14d4f$e0a3a260$2b01a8c0@broadsoft.com> <3BBD3135.C24D3240@cisco.com> <3BBD3F47.B17A734F@lmf.ericsson.se> <3BBD5410.FB6EB7EA@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>In general, I think the issue is related to a similar one we had for >>Megaco, where it was discussed how a response could be split into >>multiple "provisional" responses if it couldn't fit into a single UDP >>package. >> >>Like Brett said, using INFO like this may not be correct, but I guess > >Like you have pointed out below using a separate INFO methods for the each >chunk of response data is definitley a possibility. >But, as you might already notice, it is not a very efficient mechanism, >compared to doing it with provisional responses. it uses way more messages >between the two endpoints to accomplish this. > >So what I am trying to understand is, if there is some sort pitfall or problem >that people see in, either now or in the future permitting provisional >responses in the INFO method as part of SIP. Well, there is a thread about the possibility to CANCEL non-INVITE requests, where it has been discussed if provisional responses should be allowed for non-INVITE requests in the first place. When you design your use-case, you have to ask yourself: When the UAC sends the INFO, and start receiving multiple provisional responses, should it be allowed to - for whatever reason - CANCEL to INFO at some stage, before the final response has arrived? I think the issue here is about splitting message contents betweeen multiple SIP messages, no matter if they are requests or responses. For example, it has been agreed that there MUST NOT be any application level fragmentation of the SIP message. The question you now bring up is: should we be allowed to do application level fragmentation of message bodies. It is NOT possible for the SDP, becuase that information is needed on a SIP stack level. Also, if you send application data in the message body, and the defragmentation is done on an application level, the stack probably wouldn't even know - and probably wouldn't even care - if the message bodies in the different messages belong together or not. However, if you want the defragmentation to be done on the stack level I guess we have an issue, and if you want to do this you definately need a Require option-tag, to make sure both endpoints support it. Regards, Christer Holmberg Ericsson Finland > > Regards, > Sarvi. > > > > > that depends on exactly what you want to do. Another way would be for > > the UAS to simply return 200 to the INFO, and then send an INFO itself > > with the required data. Then, if you can't fit all data into a single > > INFO I guess you could split the data into multiple INFOs, using some > > attribute to indicate to the receiver when all data has been sent. > > > > No, I am NOT talking about any "INFO overlapping", but completely > > separate INFO transactions :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Sarvi Shanmugham wrote: > > > > > > Brett Tate wrote: > > > > > > > > Today according to the INFO RFC, the SIP INFO method is stateless, > > > > > i.e if server A issues an INFO method on an existing SIP session with > > > > > another server B, and the method body contains some data(lets say a > > > > > proprietary command, like READFILE abcd.jpg). Server B has to either > > > > > 1. come back with all the data read in the body of the 200 OK > > > > > response for the INFO method(it may be large or time consuming) > > > > > 2. do a 200 OK reponse for the INFO method with an acknowldgement > > > > > for the READ command and may be an initial chunk. The server > > > > > B may have > > > > > to send each subsequent chunk of data on a separate INFO method to A, > > > > > for which server A has to respond with a 200 OK. This could be highly > > > > > inefficient. > > > > > > > > > > I would have prefered to be able to send one INFO method and get back > > > > > multiple 18x OK methods carrying the intermediate chunks of data and > > > > > have the final chunk carry the 200 OK. > > > > > > > > Should work if using 100rel extention, however I'm > > > > sure some people might be opposed to using the INFO > > > > for this or for anything. > > > > > > This is good news. > > > We would like to use the INFO method for peer to peer communication of > > > applications on either end of the SIP session. > > > > > > > > > > > > > > > > Is there a specific reason why the the INFO > > > > > method MUST BE stateless. > > > > > > > > It isn't stateless. The specification mentions > > > > that it MUST NOT effect call state or the state > > > > of related sessions. > > > > > > > > > > Agreed. > > > Our requirement is to conduct a request/response conversation between two > > > application level entities sitting above the SIP stack on either side. > > > We do not expect any change in call or session state. > > > > > > Thanks, > > > Sarvi > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 05:26:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17615 for ; Fri, 5 Oct 2001 05:26:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00476; Fri, 5 Oct 2001 05:15:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00373 for ; Fri, 5 Oct 2001 05:15:45 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17479 for ; Fri, 5 Oct 2001 05:15:42 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f959F6g15806 for ; Fri, 5 Oct 2001 10:15:07 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Fri, 5 Oct 2001 10:14:55 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <4223WFZV>; Fri, 5 Oct 2001 10:14:43 +0100 Message-ID: From: "Chris Hogg" To: "'Victor Paulsamy'" , stoshniwal Cc: SIP , sip , brett , "'Christer Holmberg'" Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Fri, 5 Oct 2001 10:14:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14D7E.2BF948E0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C14D7E.2BF948E0 Content-Type: text/plain; charset="iso-8859-1" Hi Victor / everyone, >Just to confirm, the scenario we are talking about is > > (part 1) User A <-----> User B established with 2 streams (say) > (part 2)User A -----> User B re-INVITE Hold both streams > User A <------ User B 200 OK with Hold SDP (2 way hold) > User A -----> User B ACK and session is on hold now. > > NOW... > (part 3) User A -----> User B a re-INVITE w/o SDP >>In addition to the above two, the UAS can also send a third new SDP with >>addition/deletion/modification of new/old/old streams if it intends, as all >>characteristics of a session can be modified. Yes, if you mean the scenario (part 4) User A ----> User B a re-INVITE with modified SDP as you describe then I think this is valid. Whether or not user B accepts this SDP is of course a different matter. Does anyone else agree with this? Best Regards Chris Chris Hogg Nortel Networks (UK). -----Original Message----- From: Victor Paulsamy [mailto:victor@zapex.com] Sent: 04 October 2001 19:49 To: Hogg, Chris [MDN05:EP30:EXCH]; stoshniwal Cc: SIP; sip; brett; 'Christer Holmberg'; Victor Paulsamy Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx > Just to confirm, the scenario we are talking about is > > User A <-----> User B established with 2 streams (say) > User A -----> User B re-INVITE Hold both streams > User A <------ User B 200 OK with Hold SDP (2 way hold) > User A -----> User B ACK and session is on hold now. > > NOW... > User A -----> User B a re-INVITE w/o SDP > > Is this correct? > > > If so, I have a feeling I agree with Brett. A response to a > re-INVITE w/o SDP need not have a held SDP even if the UAS > was earlier put on hold. > > REASON: On the list it had earlier been agreed that change > of IP and/or port in ANY offer after the original INVITE > is allowed. In case of responding to a re-INVITE w/o SDP, > the offer is in the 200 OK to this re-INVITE. The UA SHOULD > be allowed to send either of: > > 1. A hold SDP (like the previous 200 OK response that it sent) > if it still wants A to be on hold. > 2. A unhold SDP as this involves only a change of IP (or > media stream) as it may now want User A to come off hold. > > What the UAS MUST NOT do is add a third stream (in addition > to the 2 already accepted originally). It is free to put one > or more of the 2 "originally in use streams" on/off hold. > > Comments please? > In addition to the above two, the UAS can also send a third new SDP with addition/deletion/modification of new/old/old streams if it intends, as all characteristics of a session can be modified. Comments? Warm regards, --victor ------_=_NextPart_001_01C14D7E.2BF948E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx

Hi Victor / everyone,

>Just to confirm, the scenario we are talking = about is
>
> (part 1) User A <-----> User = B    established with 2 streams = (say)    
> (part 2)User A  -----> User = B    re-INVITE Hold both streams
> User A <------ User B    200 = OK with Hold SDP (2 way hold)
> User A  -----> User B    = ACK and session is on hold now.
>
> NOW...
> (part 3) User A  -----> User = B    a re-INVITE w/o SDP


>>In addition to the above two, the UAS can = also send a third new SDP with
>>addition/deletion/modification of = new/old/old streams if it intends, as all
>>characteristics of a session can be = modified.

Yes, if you mean the scenario

(part 4)  User A ----> User B  a = re-INVITE with modified SDP as you describe

then I think this is valid.  Whether or not user = B accepts this SDP is of course a different matter.

Does anyone else agree with this?


Best Regards

Chris

Chris Hogg
Nortel Networks (UK).


-----Original Message-----
From: Victor Paulsamy [mailto:victor@zapex.com]
Sent: 04 October 2001 19:49
To: Hogg, Chris [MDN05:EP30:EXCH]; stoshniwal
Cc: SIP; sip; brett; 'Christer Holmberg'; Victor = Paulsamy
Subject: RE: [Sip] Open Issue #58: Rejected mid-call = SDP in 2xx


> Just to confirm, the scenario we are talking = about is
>
> User A <-----> User B    = established with 2 streams (say)
> User A  -----> User B    = re-INVITE Hold both streams
> User A <------ User B    200 = OK with Hold SDP (2 way hold)
> User A  -----> User B    = ACK and session is on hold now.
>
> NOW...
> User A  -----> User B    = a re-INVITE w/o SDP
>
> Is this correct?
>
>
> If so, I have a feeling I agree with Brett. A = response to a
> re-INVITE w/o SDP need not have a held SDP even = if the UAS
> was earlier put on hold.
>
> REASON: On the list it had earlier been agreed = that change
> of IP and/or port in ANY offer after the = original INVITE
> is allowed. In case of responding to a = re-INVITE w/o SDP,
> the offer is in the 200 OK to this re-INVITE. = The UA SHOULD
> be allowed to send either of:
>
> 1. A hold SDP (like the previous 200 OK = response that it sent)
>    if it still wants A to be on = hold.
> 2. A unhold SDP as this involves only a change = of IP (or
>    media stream) as it may now = want User A to come off hold.
>
> What the UAS MUST NOT do is add a third stream = (in addition
> to the 2 already accepted originally). It is = free to put one
> or more of the 2 "originally in use = streams" on/off hold.
>
> Comments please?
>

In addition to the above two, the UAS can also send a = third new SDP with
addition/deletion/modification of new/old/old = streams if it intends, as all
characteristics of a session can be modified.

Comments?

Warm regards,

--victor

------_=_NextPart_001_01C14D7E.2BF948E0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 06:15:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17898 for ; Fri, 5 Oct 2001 06:15:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01579; Fri, 5 Oct 2001 05:54:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01552 for ; Fri, 5 Oct 2001 05:54:50 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17799 for ; Fri, 5 Oct 2001 05:54:46 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f959sAg27644 for ; Fri, 5 Oct 2001 10:54:10 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Fri, 5 Oct 2001 10:53:53 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <4223WHR6>; Fri, 5 Oct 2001 10:53:38 +0100 Message-ID: From: "Chris Hogg" To: "'Juan-Carlos.Rojas@alcatel.fr'" Cc: "'stoshniwal@hss.hns.com'" , "'Christer Holmberg'" , brett@broadsoft.com, sip@ietf.org Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Fri, 5 Oct 2001 10:53:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14D83.9C165B90" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C14D83.9C165B90 Content-Type: text/plain; charset="iso-8859-1" Hi Juan Carlos, >So, can I conclude saying that if there was no SDP in the Invite (or re-Invite), the SDP >that can be sent by UA-A on an ACK message can only be a subset of the SDP received in the >200 message ? Yes I think this is how the appendix B of bis intends this to work - In the case of a re-INVITE with no SDP the "offer" is in the 200 OK and the "answer" is in the ACK. According to appendix B, what the UAS can offer in this case is governed by: "the offerer SHOULD offer the same SDP it provided previously if it has no reason to change anything." (In the case of a 200 OK offer). >In other words, the UA sending the ACK (which is the same that sent the Invite w/o SDP) >cannot improve the session description in this case. The "answer" is contained within the ACK. Appendix B seems to indicate that even if the "offer" did not change anything from the previous SDP (i.e. it is effectively a no-op) that the "answer" may contain SDP which is the same as the previous SDP from the answerer or MAY be different. However, the constraint in constructing all answers means that the answer "The answer to offered SDP is based on the offered SDP" (see section B.3) i.e. it must contain the same number of "m=" lines. Of course, if the UA doesn't like the offered streams in the 200 OK it can always reject them by setting the port to 0. So in answer to your question, I think the 200 OK can update the session description compared to that of the previous SDP if it has a reason to change something in the session description but the ACK MUST contain the answer which is based on this offer. >If the UA-A is not happy with this SDP, can he still issue a CANCEL message, followed by a >new re-Invite with modified SDP ? Yes, I think this is ok. From Appendix B "If the offer occurs in the 200 class response, the UAC MUST send an ACK request, with a valid answer. It MAY send a BYE request to terminate the call, or MAY generate a re-INVITE, with the offer in the INVITE, to change the session parameters back to an acceptable form." Comments? Best Regards, Chris Chris Hogg Nortel Networks (UK) -----Original Message----- From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] Sent: 04 October 2001 16:31 To: Hogg, Chris [MDN05:EP30:EXCH] Cc: 'stoshniwal@hss.hns.com'; 'Christer Holmberg'; brett@broadsoft.com; sip@ietf.org Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Hi, So, can I conclude saying that if there was no SDP in the Invite (or re-Invite), the SDP that can be sent by UA-A on an ACK message can only be a subset of the SDP received in the 200 message ? In other words, the UA sending the ACK (which is the same that sent the Invite w/o SDP) cannot improve the session description in this case. This way of reasonning seems to be very logic. If the UA-A is not happy with this SDP, can he still issue a CANCEL message, followed by a new re-Invite with modified SDP ? Is this the correct interpretation ? Best regards Juan Carlos "Chris Hogg" on 04/10/2001 16:34:56 To: "'stoshniwal@hss.hns.com'" cc: "'Christer Holmberg'" , brett@broadsoft.com, sip@ietf.org(bcc: Juan-Carlos ROJAS/FR/ALCATEL) Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Hi everyone, Siddharth's scenario is very similar to the one I was discussing with the 3pcc. Amalgamating my scerario with the one described below, "A" in Siddharth's example is equivalent to my "controller"(C). Thus after the original INV/200/ACK transaction A may send a Re-INVITE to put B on hold. But A may then subsequently send a Re-INVITE with no SDP to B. B will reply with its' current SDP which may be hold or unhold SDP. The ACK from A may contain modified SDP (i.e. modified as a result of the controller talking to some other SIP UA) but I do not think it should add any new media streams. Comments? Regards Chris Chris Hogg Nortel Networks (UK). -----Original Message----- From: stoshniwal@hss.hns.com [mailto:stoshniwal@hss.hns.com] Sent: 04 October 2001 14:59 To: Hogg, Chris [MDN05:EP30:EXCH] Cc: 'Christer Holmberg'; brett@broadsoft.com; sip@ietf.org Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Hi everyone, Please find my comments below... >> I am not sure I agree on that. Isn't the 200 for a non-SDP >> re-INVITE supposed to return the current remote SDP, and if >> the call has been put on hold that should be a call-hold >> SDP (ie the SDP that was returned in the 200 for the call >> hold re-INVITE)? Just to confirm, the scenario we are talking about is User A <-----> User B established with 2 streams (say) User A -----> User B re-INVITE Hold both streams User A <------ User B 200 OK with Hold SDP (2 way hold) User A -----> User B ACK and session is on hold now. NOW... User A -----> User B a re-INVITE w/o SDP Is this correct? If so, I have a feeling I agree with Brett. A response to a re-INVITE w/o SDP need not have a held SDP even if the UAS was earlier put on hold. REASON: On the list it had earlier been agreed that change of IP and/or port in ANY offer after the original INVITE is allowed. In case of responding to a re-INVITE w/o SDP, the offer is in the 200 OK to this re-INVITE. The UA SHOULD be allowed to send either of: 1. A hold SDP (like the previous 200 OK response that it sent) if it still wants A to be on hold. 2. A unhold SDP as this involves only a change of IP (or media stream) as it may now want User A to come off hold. What the UAS MUST NOT do is add a third stream (in addition to the 2 already accepted originally). It is free to put one or more of the 2 "originally in use streams" on/off hold. Comments please? Best regards, Siddharth. ================================= Siddharth Toshniwal Software Engineer Hughes Software Systems, Bangalore http://www.hssworld.com ------_=_NextPart_001_01C14D83.9C165B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx

Hi Juan Carlos,

>So, can I conclude saying that if there was no = SDP in the Invite (or re-Invite), the SDP  >that can be sent by = UA-A on an ACK message can only be a subset of the SDP received in the = >200 message ?

Yes I think this is how the appendix B of bis intends = this to work - In the case of a re-INVITE with no SDP the = "offer" is in the 200 OK and the "answer" is in the = ACK.  According to appendix B, what the UAS can offer in this case = is governed by:

"the offerer SHOULD offer the same SDP it
   provided previously if it has no reason = to change anything." (In the case of a 200 OK offer).

>In other words, the UA sending the ACK (which is = the same that sent the Invite w/o SDP)
>cannot improve the session description in this = case.

The "answer" is contained within the = ACK.  Appendix B seems to indicate that even if the = "offer" did not change anything from the previous SDP (i.e. = it is effectively a no-op) that the "answer" may contain SDP = which is the same as the previous SDP from the answerer or MAY be = different.  However, the constraint in constructing all answers = means that the answer "The answer to offered SDP is based on the = offered SDP" (see section B.3) i.e. it must contain the same = number of "m=3D" lines.  Of course, if the UA doesn't = like the offered streams in the 200 OK it can always reject them by = setting the port to 0.

So in answer to your question, I think the 200 OK can = update the session description compared to that of the previous SDP if = it has a reason to change something in the session description but the = ACK MUST contain the answer which is based on this offer.

>If the UA-A is not happy with this SDP, can he = still issue a CANCEL message, followed by a >new re-Invite with = modified SDP ?

Yes, I think this is ok.

From Appendix B

"If the offer occurs in the 200 class response, = the UAC
   MUST send an ACK request, with a valid = answer. It MAY send a BYE
   request to terminate the call, or MAY = generate a re-INVITE, with the
   offer in the INVITE, to change the = session parameters back to an
   acceptable form."

Comments?

Best Regards,

Chris

Chris Hogg
Nortel Networks (UK)



-----Original Message-----
From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@al= catel.fr]
Sent: 04 October 2001 16:31
To: Hogg, Chris [MDN05:EP30:EXCH]
Cc: 'stoshniwal@hss.hns.com'; 'Christer Holmberg'; = brett@broadsoft.com;
sip@ietf.org
Subject: RE: [Sip] Open Issue #58: Rejected mid-call = SDP in 2xx




Hi,

So, can I conclude saying that if there was no SDP in = the Invite (or re-Invite), the SDP that can be sent by UA-A on an ACK = message can only be a subset of the SDP received in the 200 message = ?

In other words, the UA sending the ACK (which is the = same that sent the Invite w/o SDP) cannot improve the session = description in this case.

This way of reasonning seems to be very logic. If the = UA-A is not happy with this SDP, can he still issue a CANCEL message, = followed by a new re-Invite with modified SDP ?

Is this the correct interpretation ?

Best regards

     Juan Carlos





"Chris Hogg" = <chogg@nortelnetworks.com> on 04/10/2001 16:34:56
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
 To:      = "'stoshniwal@hss.hns.com'" <stoshniwal@hss.hns.com> =
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
 cc:      = "'Christer = Holmberg'"         &nb= sp;           &nb= sp;        
          = <christer.holmberg@lmf.ericsson.se>,     =           
          = brett@broadsoft.com, sip@ietf.org(bcc: Juan-Carlos 
          = ROJAS/FR/ALCATEL)         &= nbsp;           &= nbsp;           &= nbsp;
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  
 Subject: RE: [Sip] Open Issue #58: Rejected = mid-call SDP in 
          = 2xx           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  





Hi everyone,

Siddharth's scenario is very similar to the one I was = discussing with the
3pcc. Amalgamating my scerario with the one = described below, "A" in
Siddharth's example is equivalent to my = "controller"(C).  Thus after the
original INV/200/ACK transaction A may send a = Re-INVITE to put B on hold.
But A may then subsequently send a Re-INVITE with no = SDP to B.  B will reply
with its' current SDP which may be hold or unhold = SDP.  The ACK from A may
contain modified SDP (i.e. modified as a result of = the controller talking to
some other SIP UA) but I do not think it should add = any new media streams.

Comments?

Regards

Chris

Chris Hogg
Nortel Networks (UK).





-----Original Message-----
From: stoshniwal@hss.hns.com [mailto:stoshniwal@hss.hns.com= ]
Sent: 04 October 2001 14:59
To: Hogg, Chris [MDN05:EP30:EXCH]
Cc: 'Christer Holmberg'; brett@broadsoft.com; = sip@ietf.org
Subject: RE: [Sip] Open Issue #58: Rejected mid-call = SDP in 2xx





Hi everyone,

Please find my comments below...

>> I am not sure I agree on that. Isn't the 200 = for a non-SDP
>> re-INVITE supposed to return the current = remote SDP, and if
>> the call has been put on hold that should = be a call-hold
>> SDP (ie the SDP that was returned in the = 200 for the call
>> hold re-INVITE)?

Just to confirm, the scenario we are talking about = is

User A <-----> User B    = established with 2 streams (say)
User A  -----> User B    = re-INVITE Hold both streams
User A <------ User B    200 OK = with Hold SDP (2 way hold)
User A  -----> User B    ACK = and session is on hold now.

NOW...
User A  -----> User B    a = re-INVITE w/o SDP

Is this correct?


If so, I have a feeling I agree with Brett. A = response to a
re-INVITE w/o SDP need not have a held SDP even if = the UAS
was earlier put on hold.

REASON: On the list it had earlier been agreed that = change
of IP and/or port in ANY offer after the original = INVITE
is allowed. In case of responding to a re-INVITE w/o = SDP,
the offer is in the 200 OK to this re-INVITE. The UA = SHOULD
be allowed to send either of:

1. A hold SDP (like the previous 200 OK response that = it sent)
   if it still wants A to be on = hold.
2. A unhold SDP as this involves only a change of IP = (or
   media stream) as it may now want User A = to come off hold.

What the UAS MUST NOT do is add a third stream (in = addition
to the 2 already accepted originally). It is free to = put one
or more of the 2 "originally in use = streams" on/off hold.

Comments please?

Best regards,
Siddharth.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Siddharth Toshniwal
Software Engineer
Hughes Software Systems, Bangalore
http://www.hssworld.com




------_=_NextPart_001_01C14D83.9C165B90-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 07:55:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19252 for ; Fri, 5 Oct 2001 07:55:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03931; Fri, 5 Oct 2001 07:12:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03900 for ; Fri, 5 Oct 2001 07:12:53 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18511 for ; Fri, 5 Oct 2001 07:12:46 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f95BChC12738 for ; Fri, 5 Oct 2001 13:12:43 +0200 (MEST) Received: from lmf.ericsson.se (lmf03754pc.lmf.ericsson.se [131.160.30.111]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f95BChL15971 for ; Fri, 5 Oct 2001 14:12:43 +0300 (EET DST) Message-ID: <3BBD95AA.EE2E12EB@lmf.ericsson.se> Date: Fri, 05 Oct 2001 14:12:42 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] T.38 draft status Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The -01 version of the T.38 fax draft has expired. I wonder if there is any ongoing update work, and when the next version will be released. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 10:46:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23331 for ; Fri, 5 Oct 2001 10:46:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10532; Fri, 5 Oct 2001 10:33:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10504 for ; Fri, 5 Oct 2001 10:33:11 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23175 for ; Fri, 5 Oct 2001 10:33:10 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f95EXBY09334; Fri, 5 Oct 2001 09:33:11 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f95EXAf22708; Fri, 5 Oct 2001 09:33:10 -0500 (CDT) Received: from lmf.ericsson.se (rmt160184.am.ericsson.se [138.85.160.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA28299; Fri, 5 Oct 2001 09:33:06 -0500 (CDT) Message-ID: <3BBDC8FB.58318192@lmf.ericsson.se> Date: Fri, 05 Oct 2001 17:51:39 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: stoshniwal@hss.hns.com, sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.0067D2F9.00@sampark.hss.hns.com> <3BBBF18F.BFC292B1@lmf.ericsson.se> <3BBCBF40.3C094992@lmf.ericsson.se> <3BBCD2F0.A675DC45@lmf.ericsson.se> <3BBCDAF0.36E04D75@lmf.ericsson.se> <3BBCD9AA.940E514A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer, We are repeating the same things again and again in this thread. > So, when we replace a stream with another that new stream must have the > SAME codec, the SAME attributes, and the SAME media type, and the ONLY > thing we are allowed to change is the IP address and/or the port? If we receive a re-INVITE without SDP (this is the situation we are talking about) this is true. The SDP in the 2xx will possibly differ from the SDP currently used only in the port and the IP address. Acutally if you think of the scenario it makes perfectly sense. You are involved in a session, and you get a re-INVITE. Sonce it is not you the one re-INVITing, you are not interested in changing anything. Therefore, it makes sense to return the same SDP that is being used. So, you might answer, why are we allow to change IP address and port number. Simply because some frameworks such as Java does not allow you to change the remote SDP without changing your port number. That is, a new ephemeral local port number will be assigned to you when you change the remote SDP. I hope this clarifies things. > Or, once again: are we allowed to change whatever information for a > stream in a re-INVITE SDP, but only the IP address and/or port in an ACK > SDP Yes, you got it. Regards, Gonzalo > > If that is NOT the case, the propsal of using an attribute for the call > hold will not work, since we change an attribute for an existing > stream.... > > And, the t.38 fax scenarios won't work, since we replace an audio type > stream with an image type stream... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > > > Gonzalo > > > > > > > > For example, the t.38 draft replaces an audio stream with an image (fax) > > > stream. > > > > > > Or, isn't that allowd using the ACK SDP method? > > > > > > Also, even if the codec is not changed there may be some stream specific > > > attributes (can't think of any right now, but they may be defined in > > > future) added/changed to the ACK SDP, that were not included in the > > > original SDP, which means the UAS can't send media according to those > > > sets of attributes. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > Why is this change a big deal for the UAS? > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > > Thanks for your comments! > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > > Columbia University Mobile: +358 40 702 35 35 > > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > > New York, NY 10027 > > > > USA Gonzalo.Camarillo@ericsson.com > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 10:47:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23355 for ; Fri, 5 Oct 2001 10:47:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09864; Fri, 5 Oct 2001 10:23:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09764 for ; Fri, 5 Oct 2001 10:23:40 -0400 (EDT) Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22919 for ; Fri, 5 Oct 2001 10:23:38 -0400 (EDT) Received: from medhavi ([207.113.13.1]) by illustrious.cnchost.com id KAA06325; Fri, 5 Oct 2001 10:23:36 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] MIME-Version: 1.0 Message-Id: <3BBDB4C7.000047.70601@medhavi.nextone.com> Date: Fri, 5 Oct 2001 09:25:27 -0400 (Eastern Daylight Time) Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_FMIQ0774G6G000000000" X-Mailer: IncrediMail 2001 (1500343) From: "Medhavi Bhatia" References: <002001c148e3$cf9ec730$0100000a@deewana> <3BBCD357.673E0FA6@lmf.ericsson.se> X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 To: Cc: Subject: Re: [Sip] sip based 3pcc Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --------------Boundary-00=_FMIQ0774G6G000000000 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The approach using REFER is not meant to replace the 3pcc-draft method.=0D Quite analogous to the 3pcc approach which describes how a smart controll= er=0D can instrument a 3pcc call without any extensions, the REFER based approa= ch=0D is really describing a mechanism based on REFER. All the smarts to do it have=0D to reside on the controller. The endpoint must support REFER - which most proxies=0D and UAs will do, as REFER is needed for call transfer.=0D =0D However consider the following assumptions, under which the 3pcc-draft ba= sed approach=0D breaks down:=0D =0D 1) UA does not support INVITE w/o SDP. - There are quite a lot of those. = To add to the=0D whole set of numbers, we have the SIP/H.323 interworking gateways, which probably=0D never will support such scenarios, unless they make special assumtions ab= out media.=0D =0D 2) UA will respond with a new media set of media ports whenever it is offered something=0D different from previous INV-OK-ACK.=0D =0D 3) UA will respond with a HOLD to a HOLD initiated by the peer.=0D =0D Now "flow 1" in the 3ppc draft violates (1), and can be used only in mid calls or when the UA=0D is automatic in responding with a 200 OK.=0D =0D "flow 2" fails under (2).=0D =0D "flow 3" violates (1), and gets complicated when we have (3).=0D =0D =0D =0D -------Original Message-------=0D =0D From: Gonzalo Camarillo=0D Date: Thursday, October 04, 2001 05:05:24 PM=0D To: Medhavi Bhatia=0D Cc: sip@ietf.org=0D Subject: Re: [Sip] sip based 3pcc=0D =0D Hello,=0D =0D > Some simple advantages of the technique against the one specified in=0D > Rosenberg/Peterson/Schulzrinne/Camarillo draft:=0D =0D One simple and big advantage of the=0D Rosenberg/Peterson/Schulzrinne/Camarillo draft is that you do not need=0D to use any SIP extension. That is, a controller can establish a session=0D between the simplest SIP UAs that you can get (no REFER, no Replaces,=0D etc...).=0D =0D Of course, if what you want to do is to establish a session between two=0D particular UAs that support a number of fancy features, then you can do=0D everything that those fancy features allow you to do... but I would not=0D go so far to call this an advantage over the 3pcc approach.=0D =0D Regards,=0D =0D Gonzalo=0D =0D =0D > =0D > - Controller has the option of acting as a proxy or a back=0D > to back user agent for the duration of the call after the REFER.=0D > =0D > - Controller does no have to manipulate any SDP, unless the=0D > application desires it.=0D > =0D > - Does not rely on the usage of INVITE without SDP (a large number=0D > of proxies and UAs have trouble handling it).=0D > =0D > - Does not require putting A or B on hold, which generally causes the=0D > UA to put the peer back on hold.=0D > =0D > - Does not suffer from any potential timeout issues, or assume any=0D > special behavior of the clients (some controllers use "flow 1" in the=0D > sip-3pcc draft, which works best when B is some kind of automatic=0D > device, like a media server).=0D > =0D > - Cannot cause an "infinite loop" of INVITEs (Some controllers tend to=0D > use the "flow 2" in the sip-3pcc draft, which suffers from this=0D > problem).=0D > =0D > The approach does use the SIP REFER method and the Replaces header:=0D > =0D > =0D > A Controller B=0D > | | |=0D > | create callid1 |=0D > | REFER callid1 | |=0D > |<------------------| |=0D > | | |=0D > | 202 Accepted | |=0D > |------------------>| |=0D > | | |=0D > |INVITE callid1 SDPA| |=0D > |------------------>| |=0D > | | |=0D > | | INVITE SDP A |=0D > | |----------------->|=0D > | | |=0D > | | 200 SDP B |=0D > | |<-----------------|=0D > | | |=0D > | 200 SDP B | |=0D > |<------------------| |=0D > | | |=0D > | ACK | |=0D > |------------------>| |=0D > | | |=0D > | | ACK |=0D > | |----------------->|=0D > | | |=0D > | | RTP |=0D > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|=0D > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|=0D > =0D > In this scenario, the controller has no ongoing calls with A and B=0D > in the beginning. It creates a local context for callid1. This context=0D > MUST contain a SIP call id, and MAY contain from and to tags locally=0D > generated at the controller. At this point the controller sends a=0D > REFER=0D > with the Replaces callid1 header to A. If A is interested in the call,=0D > =0D > it sends a 202 Accepted back to the controller. At this point the=0D > controller starts a timer, "timer-callid1", on callid1 for TC seconds.=0D > (TC is an application specific timer, which should at least take into=0D > account the retransmissions from A. ~10*T2 seconds is probably a good=0D > value).=0D > When the INVITE arrives from A with the Replaces callid1 header, the=0D > timer is cancelled, the INVITE is forwarded to B. At this point the=0D > controller may act as a Back to Back user agent or a proxy for the=0D > call duration, depending on the kind of application running on the=0D > controller. The 200 OK from B arrives and is forwared to A. This way=0D > the controller does not need to assume anything about what SDP will=0D > be used for the call.=0D > =0D > 1. Controller creates SIP call leg 1 (Call id=3D12345%40192.168.118.3;=0D >to-tag=3D12345;from-tag=3D5FFE-3994), and sends a REFER to=0D > A:=0D > =0D > REFER sip:A@agentland SIP/2.0=0D > Via: SIP/2.0/UDP controller.nextone.net=0D > To: =0D > From: ;tag=3D193402342=0D > Call-ID: 898234234@controller.nextone.net=0D > CSeq: 93809823 REFER=0D > Refer-To:=0D > to-tag=3D12345;from-tag=3D5FFE-3994>=0D > Referred-By: =0D > Contact: sip:B@controller.nextone.net=0D > Content-Length: 0=0D > =0D > Note the presence of the To tag, even though the INVITE is=0D > being sent by A. The Controller may or may not put the To tag.=0D > =0D > 2. B sends a 202 Accepted to the Controller.=0D > =0D > 3. B sends an INVITE to the Controller=0D > =0D > INVITE=0D > to-tag=3D12345;from-tag=3D5FFE-3994> SIP/2.0=0D > Via: SIP/2.0/UDP sip:A@agentland=0D > From: A ;tag=3D3pcc=0D > To: B =0D > Call-ID: 31415@agentland=0D > CSeq: 1 INVITE=0D > Contact: A@agentland=0D > =0D > MID-call:=0D > =0D > The same mechanism can be used in the middle of a call. This is the=0D > scenario when the controller already has a call up with A. The only=0D > change in this case is that the REFER is sent on the existing call=0D > leg.=0D > The call flows in this case are similar to the call transfer call=0D > flows given the sip-call-transfer draft. In this case A sends a NOTIFY=0D > back to the controller, containing the status of the REFER, and the=0D > controller disconnects the old call with A by sending a BYE to it.=0D > =0D > =0D > A Controller B=0D > | | |=0D > | | |=0D > | REFER callid1 | |=0D > |<------------------| |=0D > | | |=0D > | 202 Accepted | |=0D > |------------------>| |=0D > | | |=0D > |INVITE callid1 SDPA| |=0D > |------------------>| |=0D > | | |=0D > | | INVITE SDP A |=0D > | |----------------->|=0D > | | |=0D > | | 200 SDP B |=0D > | |<-----------------|=0D > | | |=0D > | 200 SDP B | |=0D > |<------------------| |=0D > | | |=0D > | ACK | |=0D > |------------------>| |=0D > | | |=0D > | | ACK |=0D > | |----------------->|=0D > | NOTIFY (200 OK) | |=0D > |------------------>| |=0D > | | |=0D > | 200 OK | |=0D > |<------------------| |=0D > | | |=0D > | BYE | |=0D > |<------------------| |=0D > | | |=0D > | | RTP |=0D > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|=0D > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|=0D =0D -- =0D Gonzalo Camarillo Phone : +1 212 939 71 71=0D Columbia University Mobile: +358 40 702 35 35=0D 472 Computer Science Building Fax : +358 9 299 30 52=0D 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo=0D New York, NY 10027 =0D USA Gonzalo.Camarillo@ericsson.com --------------Boundary-00=_FMIQ0774G6G000000000 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The approach using REFER is not meant to replace the 3pcc-draf= t=20 method.
Quite analogous to the 3pcc approach which describes how a sma= rt=20 controller
can instrument a 3pcc call without any extensions, the REFER b= ased=20 approach
is really describing a mechanism based on REFER. All the smart= s to do=20 it have
to reside on the controller. The endpoint must support REFER -= which=20 most proxies
and UAs will do, as REFER is needed for call transfer.
 
However consider the following assumptions, under which the=20 3pcc-draft based approach
breaks down:
 
1) UA does not support INVITE w/o SDP. - There are quite a lot= of=20 those. To add to the
whole set of numbers, we have the SIP/H.323 interworking gatew= ays,=20 which probably
never will support such scenarios, unless they make special=20 assumtions about media.
 
2) UA will respond with a new media set of media ports wheneve= r it is=20 offered something
different from previous INV-OK-ACK.
 
3) UA will respond with a HOLD to a HOLD initiated by the peer= =2E
 
Now "flow 1" in the 3ppc draft violates (1), and can be used o= nly in=20 mid calls or when the UA
is automatic in responding with a 200 OK.
 
"flow 2" fails under (2).
 
"flow 3" violates (1), and gets complicated when we have (3).<= /DIV>
 
 
 
-------Original Message-------<= /I>
 
From: Gonzalo=20 Camarillo
Date: Thursd= ay, October=20 04, 2001 05:05:24 PM
To: Medhavi Bhatia
Cc: sip@ietf.org
Subject: Re:= [Sip] sip=20 based 3pcc
 
Hello,

> Some simple advantages of the=20 technique against the one specified in
>=20 Rosenberg/Peterson/Schulzrinne/Camarillo draft:

One simple a= nd big=20 advantage of the
Rosenberg/Peterson/Schulzrinne/Camarillo draft = is that=20 you do not need
to use any SIP extension. That is, a controller = can=20 establish a session
between the simplest SIP UAs that you can ge= t (no=20 REFER, no Replaces,
etc...).

Of course, if what you want = to do=20 is to establish a session between two
particular UAs that suppor= t a=20 number of fancy features, then you can do
everything that those = fancy=20 features allow you to do... but I would not
go so far to call th= is an=20 advantage over the 3pcc=20 approach.

Regards,

Gonzalo


>
> -= =20 Controller has the option of acting as a proxy or a back
> to= back=20 user agent for the duration of the call after the REFER.
> >=20 - Controller does no have to manipulate any SDP, unless the
>= =20 application desires it.
>
> - Does not rely on the usa= ge of=20 INVITE without SDP (a large number
> of proxies and UAs have = trouble=20 handling it).
>
> - Does not require putting A or B on= hold,=20 which generally causes the
> UA to put the peer back on=20 hold.
>
> - Does not suffer from any potential timeout= =20 issues, or assume any
> special behavior of the clients (some= =20 controllers use "flow 1" in the
> sip-3pcc draft, which works= best=20 when B is some kind of automatic
> device, like a media=20 server).
>
> - Cannot cause an "infinite loop" of INVI= TEs=20 (Some controllers tend to
> use the "flow 2" in the sip-3pcc = draft,=20 which suffers from this
> problem).
>
> The appr= oach=20 does use the SIP REFER method and the Replaces header:
>
= >=20
> A Controller B
> | | |
> | create callid1 |> |=20 REFER callid1 | |
> |<------------------| |
> | | |<= BR>>=20 | 202 Accepted | |
> |------------------>| |
> | |=20 |
> |INVITE callid1 SDPA| |
> |------------------>|=20 |
> | | |
> | | INVITE SDP A |
> |=20 |----------------->|
> | | |
> | | 200 SDP B |
&g= t; |=20 |<-----------------|
> | | |
> | 200 SDP B | |
&g= t;=20 |<------------------| |
> | | |
> | ACK | |
>=20 |------------------>| |
> | | |
> | | ACK |
> = |=20 |----------------->|
> | | |
> | | RTP |
>=20 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
>=20 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
>
> In this=20 scenario, the controller has no ongoing calls with A and B
> = in the=20 beginning. It creates a local context for callid1. This context
= >=20 MUST contain a SIP call id, and MAY contain from and to tags=20 locally
> generated at the controller. At this point the cont= roller=20 sends a
> REFER
> with the Replaces callid1 header to A= =2E If A=20 is interested in the call,
>
> it sends a 202 Accepted= back=20 to the controller. At this point the
> controller starts a ti= mer,=20 "timer-callid1", on callid1 for TC seconds.
> (TC is an appli= cation=20 specific timer, which should at least take into
> account the= =20 retransmissions from A. ~10*T2 seconds is probably a good
>=20 value).
> When the INVITE arrives from A with the Replaces ca= llid1=20 header, the
> timer is cancelled, the INVITE is forwarded to = B. At=20 this point the
> controller may act as a Back to Back user ag= ent or=20 a proxy for the
> call duration, depending on the kind of=20 application running on the
> controller. The 200 OK from B ar= rives=20 and is forwared to A. This way
> the controller does not need= to=20 assume anything about what SDP will
> be used for the call.>=20
> 1. Controller creates SIP call leg 1 (Call=20 id=3D12345%40192.168.118.3;
>to-tag=3D12345;from-tag=3D5FFE-3= 994), and=20 sends a REFER to
> A:
>
> REFER sip:A@agentland=20 SIP/2.0
> Via: SIP/2.0/UDP controller.nextone.net
> To:= =20 <sip:A@agentland>
> From: <sip:B@controller.nextone.net>;tag=3D193402342
>=20 Call-ID: 898234234@controll= er.nextone.net
>=20 CSeq: 93809823 REFER
> Refer-To:
> <sip:B@controller@nextone.net?Replaces:12345%40192.168.118.3;
>= to-tag=3D12345;from-tag=3D5FFE-3994>
>=20 Referred-By: <sip:B@controller.nextone.net>
>=20 Contact: sip:B@controller.nextone.net
>=20 Content-Length: 0
>
> Note the presence of the To tag,= even=20 though the INVITE is
> being sent by A. The Controller may or= may=20 not put the To tag.
>
> 2. B sends a 202 Accepted to t= he=20 Controller.
>
> 3. B sends an INVITE to the=20 Controller
>
> INVITE
> <sip:B@controller@nextone.net?Replaces:12345%40192.168.118.3;
>= to-tag=3D12345;from-tag=3D5FFE-3994>=20 SIP/2.0
> Via: SIP/2.0/UDP sip:A@agentland
> From: A=20 <sip:A@agentland>;tag=3D3pcc
> To: B <B@controller@nextone.net>
>=20 Call-ID: 31415@agentland
> CSeq: 1 INVITE
> Contact:=20 A@agentland
>
> MID-call:
>
> The same me= chanism=20 can be used in the middle of a call. This is the
> scenario w= hen the=20 controller already has a call up with A. The only
> change in= this=20 case is that the REFER is sent on the existing call
> leg.>=20 The call flows in this case are similar to the call transfer call>=20 flows given the sip-call-transfer draft. In this case A sends a=20 NOTIFY
> back to the controller, containing the status of the= REFER,=20 and the
> controller disconnects the old call with A by sendi= ng a=20 BYE to it.
>
>
> A Controller B
> | | |>=20 | | |
> | REFER callid1 | |
> |<------------------|=20 |
> | | |
> | 202 Accepted | |
>=20 |------------------>| |
> | | |
> |INVITE callid1 SD= PA|=20 |
> |------------------>| |
> | | |
> | | INVI= TE SDP=20 A |
> | |----------------->|
> | | |
> | | 200= SDP B=20 |
> | |<-----------------|
> | | |
> | 200 SDP= B |=20 |
> |<------------------| |
> | | |
> | ACK |=20 |
> |------------------>| |
> | | |
> | | ACK=20 |
> | |----------------->|
> | NOTIFY (200 OK) | |>=20 |------------------>| |
> | | |
> | 200 OK | |
&g= t;=20 |<------------------| |
> | | |
> | BYE | |
>=20 |<------------------| |
> | | |
> | | RTP |
>=20 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
>=20 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|

--
Gonzalo Cama= rillo=20 Phone : +1 212 939 71 71
Columbia University Mobile: +358 40 702= 35=20 35
472 Computer Science Building Fax : +358 9 299 30 52
1214=20 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo<= BR>New=20 York, NY 10027
USA Gonzalo.Camarillo@er= icsson.com
=09 =09 =09 =09 =09 =09 =09
_________________________________________________
IncrediMail - Email has finally= =20 evolved - Click=20 Here --------------Boundary-00=_FMIQ0774G6G000000000-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 10:52:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23405 for ; Fri, 5 Oct 2001 10:52:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10045; Fri, 5 Oct 2001 10:29:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10014 for ; Fri, 5 Oct 2001 10:29:00 -0400 (EDT) Received: from rwcxch02.clarent.com ([208.205.112.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23032 for ; Fri, 5 Oct 2001 10:28:58 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Oct 2001 07:27:29 -0700 Received: from rwcjfmule01 (adsl-64-169-17-213.dsl.snfc21.pacbell.net [64.169.17.213]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TYCRF3FD; Fri, 5 Oct 2001 07:27:26 -0700 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" , sip@ietf.org Subject: RE: [Sip] T.38 draft status Date: Fri, 5 Oct 2001 07:28:07 -0700 Message-ID: <008301c14da9$f402a3b0$d511a940@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3BBD95AA.EE2E12EB@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am planning to submit an updated draft-02 very soon based on: - changes to indicate echo cancelation/silence suppression media attributes for fax pass-through (done), - comments & suggestions submitted by Bill Sulzen of Cisco (on-going) - first testing at the August SIPit event between 2 gateway vendors. The first fax calls were successful and we agreed to add some text to indicate how the faxratemanagement media attribute should be "negotiated" (done) Recent events have prevented me from being on target but I expect the draft to be out within 2 weeks. Regards, Jean-Francois. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Christer Holmberg > Sent: Friday, October 05, 2001 4:13 AM > To: sip@ietf.org > Subject: [Sip] T.38 draft status > > > > Hi, > > The -01 version of the T.38 fax draft has expired. I wonder > if there is > any ongoing update work, and when the next version will be released. > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 11:04:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23665 for ; Fri, 5 Oct 2001 11:03:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10962; Fri, 5 Oct 2001 10:50:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10931 for ; Fri, 5 Oct 2001 10:50:13 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23392 for ; Fri, 5 Oct 2001 10:50:11 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f95En5C25191 for ; Fri, 5 Oct 2001 10:49:05 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAB44513 (AUTH pkyzivat); Fri, 5 Oct 2001 10:51:04 -0400 (EDT) Message-ID: <3BBDC823.1F18E441@cisco.com> Date: Fri, 05 Oct 2001 10:48:03 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Proposed change to callerprefs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I posted the question attached to the end of this to sip-implementors a week or so age. Since then I have considered the question further and have come to the conclusion that while the interpretation I reached was probably valid and functional, it is a confusing interpretation. I now believe it would be better to revise the callerprefs proposal so that the issues may be handled in a more consistent, less confusing way. In my earlier posting, I posed the problem of specifying a preference for a contact supporting both english and spanish language. According to draft-ietf-sip-callerprefs-04 language="en,es" means english OR spanish, while language="en",language="es" means english AND spanish. The trouble with this is it violates the principle of least astonishment. I believe most people will expect language="en,es" and language="en",language="es" to mean the same thing. For precedent we need look no further than the normal header processing logic in sip, which says that: Accept-Contact:*;language="en", *;language="es" is equivalent to: Accept-Contact:*;language="en" Accept-Contact:*;language="es" So, I propose that: language="en,es" should be equivalent to: language="en",language="es" and that this should require a match on both english AND spanish. The reason this means AND rather than OR is consistency with the combination of cp-params of different types: language="en",media="audio" means english AND audio, so language="en",language="es" should mean english AND spanish Unfortunately this interpretation is a change from the current draft. In addition to the consistency argument, practicality also supports this change. For one thing, there is more need to express an AND condition than an OR condition, and so it ought to be more concise. Also, there is already another way to express the OR condition. If I want english or spanish, I can write: Accept-Contact:*;language="en", *;language="es" There is one more issue to deal with if this change is to be made. Consider Accept-Contact:*;media="voice";media="video";q=1.0, *;media="voice";media="!video";q=.5 This ought to be equivalent to Accept-Contact:*;media="voice,video";q=1.0, *;media="voice,!video";q=.5 but this would be wrong because "!" is only valid at the beginning of the parameter value, and applies the value as a whole rather than to a particular item in the comma separated list of items in the value. For consistency, I propose that this also be changed. Negation through use of "!" should apply to an individual element in a comma separated list of values. For example (yes, I know this is nonsense), suppose I want to accept contacts supporting english but neither spanish nor french. (english AND NOT(spanish OR french)) This can be written: Accept-Contact:*;language="en,!es,!fr" If instead I wanted to accept (english AND ((NOT spanish) OR (NOT french)) I would write: Accept-Contact:*;language="en,!es", *;language="en,!fr" If there is agreement on this proposal then I am willing to draft a revision to draft-ietf-sip-callerprefs-04 that reflects it. But I don't want to go th the trouble unless there is agreement that this is a good thing. If there isn't agreement with this proposal, then I at least hope to get agreement that the interpretation I posed in the message below is correct. It is essential that there be some way to express the AND condition for two values of the same cp-param type. Paul Kyzivat Cisco Systems -------- Original Message -------- Subject: [Sip-implementors] Need clarification on callerprefs Date: Thu, 27 Sep 2001 10:26:57 -0400 From: Paul Kyzivat To: sip-implementors@cs.columbia.edu References: <008501c13792$ce9f8c00$0601a8c0@oleane.com> I have a question on the matching algorithm in callerprefs. Suppose I need a rule that requires multiple distinct values for the same kind of param - for instance I need a contact that supports both English and Spanish. If I match: Accept-Contact *;language="en,es" against: Contact: sip:joe@example.com;language="en" Contact: sip:bob@example.com;language="de,en" Contact: sip:alice@example.com;language="en,es,fi" it will match both joe and alice, which is not what I want. I believe that the following should do the right thing: Accept-Contact *;language="en";language="es" I find nothing in the draft that forbids this, but neither do I find anything that convinces me that this is intended behavior either. Can someone confirm that this is valid usage, and that a server which failed to support it would be non-conforming? Paul Kyzivat _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 11:14:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23805 for ; Fri, 5 Oct 2001 11:14:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10745; Fri, 5 Oct 2001 10:43:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10714 for ; Fri, 5 Oct 2001 10:43:55 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23305 for ; Fri, 5 Oct 2001 10:43:53 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f95EhFs13256; Fri, 5 Oct 2001 10:43:15 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA25561; Fri, 5 Oct 2001 09:43:14 -0500 (CDT) Message-ID: <3BBDC6FC.E50AF55D@lucent.com> Date: Fri, 05 Oct 2001 09:43:08 -0500 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP LIST CC: Jonathan Rosenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Request merging Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Can someone please confirm what is the current status of request merging for proxies? I recall that there was some discussion on the list a few weeks ago that deprecated request merging for proxies and put the onus on UAs. Are proxies NOT supposed to handle request merging anymore? If that is the case, Jonathan's page on this topic should probably be updated to this effect. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 11:20:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23945 for ; Fri, 5 Oct 2001 11:20:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11112; Fri, 5 Oct 2001 10:56:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11083 for ; Fri, 5 Oct 2001 10:56:29 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23468 for ; Fri, 5 Oct 2001 10:56:27 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AA188FF3013C; Fri, 05 Oct 2001 10:56:24 -0400 Message-ID: <00eb01c14dad$9d5d4160$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" , "Sarvi Shanmugham" Cc: , References: <003101c14d4f$e0a3a260$2b01a8c0@broadsoft.com> <3BBD3135.C24D3240@cisco.com> <3BBD3F47.B17A734F@lmf.ericsson.se> <3BBD5410.FB6EB7EA@cisco.com> <3BBD5CB7.2A47C256@lmf.ericsson.se> Subject: Re: [Sip] SIP INFO method - Any reason it MUST BE stateless. Date: Fri, 5 Oct 2001 10:54:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, As Christer points out, there has been some debate as to whether provisional responses should be allowed for non-INVITE transactions (with the exception of 100-Trying). This is related to "Open Issue #7: CANCEL for non-INVITE". Although consensus has not been declared, it appears to me that the SIP WG is leaning toward not allowing provisional responses to non-INVITE requests and not allowing CANCEL for non-INVITE transactions. Therefore, it may turn out that you will be required to answer an INFO request with a more-or-less immediate 2xx response. But I think there is another way. Maybe you could borrow the "206 Partial Content" response code from HTTP. You could use that in your INFO response to indicate that there is more data that the client needs to request. You may need to include some information in the body of the response for the client to include in the body of subsequent requests so the server could correlate the requests and know which chunks had been sent. In other words, the state would be in the body and the defragmentation would have to be done by a user agent that understands the body. To any proxies along the way, each INFO would look like an ordinary non-INVITE request. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Christer Holmberg" To: "Sarvi Shanmugham" Cc: ; Sent: Friday, October 05, 2001 3:09 AM Subject: Re: [Sip] SIP INFO method - Any reason it MUST BE stateless. > > Hi, > > >>In general, I think the issue is related to a similar one we had for > >>Megaco, where it was discussed how a response could be split into > >>multiple "provisional" responses if it couldn't fit into a single UDP > >>package. > >> > >>Like Brett said, using INFO like this may not be correct, but I guess > > > >Like you have pointed out below using a separate INFO methods for the each > >chunk of response data is definitley a possibility. > >But, as you might already notice, it is not a very efficient mechanism, > >compared to doing it with provisional responses. it uses way more messages > >between the two endpoints to accomplish this. > > > >So what I am trying to understand is, if there is some sort pitfall or problem > >that people see in, either now or in the future permitting provisional > >responses in the INFO method as part of SIP. > > Well, there is a thread about the possibility to CANCEL non-INVITE > requests, where it has been discussed if provisional responses should be > allowed for non-INVITE requests in the first place. > > When you design your use-case, you have to ask yourself: When the UAC > sends the INFO, and start receiving multiple provisional responses, > should it be allowed to - for whatever reason - CANCEL to INFO at some > stage, before the final response has arrived? > > I think the issue here is about splitting message contents betweeen > multiple SIP messages, no matter if they are requests or responses. For > example, it has been agreed that there MUST NOT be any application level > fragmentation of the SIP message. The question you now bring up is: > should we be allowed to do application level fragmentation of message > bodies. It is NOT possible for the SDP, becuase that information is > needed on a SIP stack level. > > Also, if you send application data in the message body, and the > defragmentation is done on an application level, the stack probably > wouldn't even know - and probably wouldn't even care - if the message > bodies in the different messages belong together or not. > > However, if you want the defragmentation to be done on the stack level I > guess we have an issue, and if you want to do this you definately need a > Require option-tag, to make sure both endpoints support it. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > Regards, > > Sarvi. > > > > > > > > that depends on exactly what you want to do. Another way would be for > > > the UAS to simply return 200 to the INFO, and then send an INFO itself > > > with the required data. Then, if you can't fit all data into a single > > > INFO I guess you could split the data into multiple INFOs, using some > > > attribute to indicate to the receiver when all data has been sent. > > > > > > No, I am NOT talking about any "INFO overlapping", but completely > > > separate INFO transactions :) > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > Sarvi Shanmugham wrote: > > > > > > > > Brett Tate wrote: > > > > > > > > > > Today according to the INFO RFC, the SIP INFO method is stateless, > > > > > > i.e if server A issues an INFO method on an existing SIP session with > > > > > > another server B, and the method body contains some data(lets say a > > > > > > proprietary command, like READFILE abcd.jpg). Server B has to either > > > > > > 1. come back with all the data read in the body of the 200 OK > > > > > > response for the INFO method(it may be large or time consuming) > > > > > > 2. do a 200 OK reponse for the INFO method with an acknowldgement > > > > > > for the READ command and may be an initial chunk. The server > > > > > > B may have > > > > > > to send each subsequent chunk of data on a separate INFO method to A, > > > > > > for which server A has to respond with a 200 OK. This could be highly > > > > > > inefficient. > > > > > > > > > > > > I would have prefered to be able to send one INFO method and get back > > > > > > multiple 18x OK methods carrying the intermediate chunks of data and > > > > > > have the final chunk carry the 200 OK. > > > > > > > > > > Should work if using 100rel extention, however I'm > > > > > sure some people might be opposed to using the INFO > > > > > for this or for anything. > > > > > > > > This is good news. > > > > We would like to use the INFO method for peer to peer communication of > > > > applications on either end of the SIP session. > > > > > > > > > > > > > > > > > > > > Is there a specific reason why the the INFO > > > > > > method MUST BE stateless. > > > > > > > > > > It isn't stateless. The specification mentions > > > > > that it MUST NOT effect call state or the state > > > > > of related sessions. > > > > > > > > > > > > > Agreed. > > > > Our requirement is to conduct a request/response conversation between two > > > > application level entities sitting above the SIP stack on either side. > > > > We do not expect any change in call or session state. > > > > > > > > Thanks, > > > > Sarvi > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 11:20:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23956 for ; Fri, 5 Oct 2001 11:20:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11316; Fri, 5 Oct 2001 10:58:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11287 for ; Fri, 5 Oct 2001 10:58:22 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23487 for ; Fri, 5 Oct 2001 10:58:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f95Eul8P002790; Fri, 5 Oct 2001 10:56:47 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4KFCAHZM>; Fri, 5 Oct 2001 10:57:52 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E668@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Sarvi Shanmugham'" , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-cc-transfer-05 Date: Fri, 5 Oct 2001 10:57:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Look for threads back in the Dec 2000 / Feb 2001 timeframe (check the minutes of the Dec ietf and the Feb interim meeting). I've got the reasoning below - REFER is not INVITE. The non-INVITE transaction model times out quickly whether there are provisional responses or not. (There have been other threads on disallowing provisionals for non-INVITEs. They are allowed currently but they don't cause the transaction to wait any longer for a final response). I'm not sure I understand your third paragraph. Nothing in the current drafts prevents you from issuing NOTIFYs with progress information if you wish to expose it. (One could have a sipfrag with a status line of 183 for example). RjS > -----Original Message----- > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > Sent: Thursday, October 04, 2001 11:21 PM > To: Robert Sparks > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-cc-transfer-05 > > > Hi Robert, > Could you please refer me to the thread that discusses this. > > What is the reasoning for not allowing provisional responses > to the REFER > method. > > Seems to me, that would be the cleaner way of doing this than > a one time > REGISTER with a NOTIFY option. > > As with this method, the Transferor cannot get intermediate > status of how > the transfer is going. The transferor application may want do > certain things > based on that status. > One example on a TELE-to-SIP gateway, would be a choice of > when the TELE > side should be disconnected or dropped. > The application might want to keep the telephony leg active till, > 1. the Transferee ACKs the REFER(which I believe > doesn't necessarily > mean the phone is ringing) > 2. the Transferee says the destination is ringing(may > be he wants to > reconnect if the destination comes back as a ring no-answer. > 3. the Transferee says the destination is connected. > > Thanks, > Sarvi > > Robert Sparks wrote: > > > If only we could... > > > > No. Non-INVITE transactions do not pend. They must > > complete immediately. If you've been following the > > open issues threads, you'll have seen the suggestion > > to kill off provisional responses (other than a 100 > > Trying to quench retransmissions) to non-INVITES. > > > > This feature of the non-INVITE transaction model is > > why we have the implicit subscribe and the separate > > NOTIFY instead of just waiting for the triggered > > action to complete before sending the final response > > to the REFER (on a historical note, that was the original > > proposal of over a year ago). > > > > RjS > > > > > -----Original Message----- > > > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > > > Sent: Tuesday, September 25, 2001 11:57 AM > > > To: sip@ietf.org > > > Subject: [Sip] draft-ietf-sip-cc-transfer-05 > > > > > > > > > > > > I have a question/concern in the blind transfer case. > > > > > > As per the current spec, > > > The TRANSFEREE responds with a Ack 202 to the REFER > method, before > > > the attempt to the Transfer target is initiated. > > > > > > The next possible message from the Transferee to the > Transferor is > > > NOTIFY(200 OK) and this is when the Transfer target > > > accepts(picks up the > > > phone). > > > > > > In a blind transfer, where I want to release the > > > Transferor, Ack202 > > > "may be" premature, and NOTIFY(200 OK) may be too late. > > > > > > Can the Transferee gateway, send an intermediate > NOTIFY(180 OK) > > > when the transfer target is "ringing". This could be a > more reliable > > > place to release the Transferee's line, than Ack 202 > > > > > > Any thoughts, > > > Sarvi > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 11:23:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24102 for ; Fri, 5 Oct 2001 11:23:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11235; Fri, 5 Oct 2001 10:57:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11135 for ; Fri, 5 Oct 2001 10:57:11 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23474 for ; Fri, 5 Oct 2001 10:57:09 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f95Eu9S14226 for ; Fri, 5 Oct 2001 10:56:09 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 5 Oct 2001 10:56:20 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <42PMDH4G>; Fri, 5 Oct 2001 10:56:10 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514FC1A@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Sarvi Shanmugham'" , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-cc-transfer-05 Date: Fri, 5 Oct 2001 10:56:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14DAD.DC268F00" X-Orig: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C14DAD.DC268F00 Content-Type: text/plain; charset="iso-8859-1" The problem with allowing provisional responses to REFER is that the REFER transaction will generally time out long before the triggered call is answered. This was discussed at the 49th IETF: the slides may still be available at http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe r-02.htm There were a number of REFER threads at the turn of the year. I suppose "Solving the REFER retransmit issue" (beginning 12/12/2000) might be a typical one. -----Original Message----- From: Sarvi Shanmugham [mailto:sarvi@cisco.com] Sent: Friday, October 05, 2001 12:21 AM To: Robert Sparks Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-cc-transfer-05 Hi Robert, Could you please refer me to the thread that discusses this. What is the reasoning for not allowing provisional responses to the REFER method. Seems to me, that would be the cleaner way of doing this than a one time REGISTER with a NOTIFY option. As with this method, the Transferor cannot get intermediate status of how the transfer is going. The transferor application may want do certain things based on that status. One example on a TELE-to-SIP gateway, would be a choice of when the TELE side should be disconnected or dropped. The application might want to keep the telephony leg active till, 1. the Transferee ACKs the REFER(which I believe doesn't necessarily mean the phone is ringing) 2. the Transferee says the destination is ringing(may be he wants to reconnect if the destination comes back as a ring no-answer. 3. the Transferee says the destination is connected. Thanks, Sarvi Robert Sparks wrote: > If only we could... > > No. Non-INVITE transactions do not pend. They must > complete immediately. If you've been following the > open issues threads, you'll have seen the suggestion > to kill off provisional responses (other than a 100 > Trying to quench retransmissions) to non-INVITES. > > This feature of the non-INVITE transaction model is > why we have the implicit subscribe and the separate > NOTIFY instead of just waiting for the triggered > action to complete before sending the final response > to the REFER (on a historical note, that was the original > proposal of over a year ago). > > RjS > > > -----Original Message----- > > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > > Sent: Tuesday, September 25, 2001 11:57 AM > > To: sip@ietf.org > > Subject: [Sip] draft-ietf-sip-cc-transfer-05 > > > > > > > > I have a question/concern in the blind transfer case. > > > > As per the current spec, > > The TRANSFEREE responds with a Ack 202 to the REFER method, before > > the attempt to the Transfer target is initiated. > > > > The next possible message from the Transferee to the Transferor is > > NOTIFY(200 OK) and this is when the Transfer target > > accepts(picks up the > > phone). > > > > In a blind transfer, where I want to release the > > Transferor, Ack202 > > "may be" premature, and NOTIFY(200 OK) may be too late. > > > > Can the Transferee gateway, send an intermediate NOTIFY(180 OK) > > when the transfer target is "ringing". This could be a more reliable > > place to release the Transferee's line, than Ack 202 > > > > Any thoughts, > > Sarvi > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C14DAD.DC268F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sip-cc-transfer-05

The problem with allowing provisional responses to = REFER is that the REFER transaction will generally time out long before = the triggered call is answered.  This was discussed at the 49th = IETF: the slides may still be available at

http://www.softarmor.com/sipwg/meets/ietf49/slides/dra= ft-ietf-sip-cc-transfer-02.htm

There were a number of REFER threads at the turn of = the year.  I suppose "Solving the REFER retransmit = issue" (beginning 12/12/2000) might be a typical one.

-----Original Message-----
From: Sarvi Shanmugham [mailto:sarvi@cisco.com]
Sent: Friday, October 05, 2001 12:21 AM
To: Robert Sparks
Cc: sip@ietf.org
Subject: Re: [Sip] = draft-ietf-sip-cc-transfer-05


Hi Robert,
      Could you please = refer me to the thread that discusses this.

What is the reasoning for not allowing provisional = responses to the REFER
method.

Seems to me, that would be the cleaner way of doing = this than a one time
REGISTER with a NOTIFY option.

As with this method, the Transferor cannot get = intermediate status of how
the transfer is going. The transferor application = may want do certain things
based on that status.
One example on a TELE-to-SIP gateway, would be a = choice of when the TELE
side should be disconnected or dropped.
The application might want to keep the telephony leg = active till,
       1. the = Transferee ACKs the REFER(which I believe doesn't necessarily
mean the phone is ringing)
       2. the = Transferee says the destination is ringing(may be he wants to
reconnect if the destination comes back as a ring = no-answer.
      3. the Transferee = says the destination is connected.

Thanks,
Sarvi

Robert Sparks wrote:

> If only we could...
>
> No. Non-INVITE transactions do not pend. They = must
> complete immediately. If you've been following = the
> open issues threads, you'll have seen the = suggestion
> to kill off provisional responses (other than a = 100
> Trying to quench retransmissions) to = non-INVITES.
>
> This feature of the non-INVITE transaction = model is
> why we have the implicit subscribe and the = separate
> NOTIFY instead of just waiting for the = triggered
> action to complete before sending the final = response
> to the REFER (on a historical note, that was = the original
> proposal of over a year ago).
>
> RjS
>
> > -----Original Message-----
> > From: Sarvi Shanmugham [mailto:sarvi@cisco.com]
> > Sent: Tuesday, September 25, 2001 11:57 = AM
> > To: sip@ietf.org
> > Subject: [Sip] = draft-ietf-sip-cc-transfer-05
> >
> >
> >
> > I have a question/concern in the blind = transfer case.
> >
> > As per the current spec,
> >     The TRANSFEREE = responds with a Ack 202 to the REFER method, before
> > the attempt to the Transfer target is = initiated.
> >
> >     The next possible = message from the Transferee to the Transferor is
> > NOTIFY(200 OK) and this is when the = Transfer target
> > accepts(picks up the
> > phone).
> >
> >      In a blind = transfer, where I want to release the
> > Transferor, Ack202
> > "may be" premature, and = NOTIFY(200 OK) may be too late.
> >
> >      Can the = Transferee gateway, send an intermediate NOTIFY(180 OK)
> > when the transfer target is = "ringing". This could be a more reliable
> > place to release the Transferee's line, = than Ack 202
> >
> > Any thoughts,
> > Sarvi
> >
>
> = _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip

------_=_NextPart_001_01C14DAD.DC268F00-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 11:33:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24323 for ; Fri, 5 Oct 2001 11:33:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12085; Fri, 5 Oct 2001 11:12:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12057 for ; Fri, 5 Oct 2001 11:12:47 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23785 for ; Fri, 5 Oct 2001 11:12:44 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f95FCGx23831 for ; Fri, 5 Oct 2001 11:12:16 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4RWWGX>; Fri, 5 Oct 2001 16:12:10 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC33C4@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'Jonathan Lennox'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] bis draft: Headers in 100 Trying (was "Minor NIT on Sup ported header") Date: Fri, 5 Oct 2001 16:12:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org See below Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Jonathan Lennox[SMTP:lennox@cs.columbia.edu] > Sent: 28 September 2001 19:47 > To: Drage, Keith (Keith) > Cc: 'sip@ietf.org' > Subject: Re: [Sip] bis draft: Minor NIT on Supported header > > On Friday, September 28 2001, "Drage, Keith (Keith)" wrote to > "'sip@ietf.org'" saying: > > > Does anybody see any purpose for any headers other than From; To; > Call-ID; > > CSeq; Via; and Content-Length within a 100 Trying response. > > In addition to the two Vijay mentioned (Server and Timestamp), I don't see > anything wrong with including Date. Some servers, including ours, insert > it > in every message generated. (In a 100 it's probably roughly as useful as > Server, i.e. it's good for debugging and for diagnosing various abnormal > situations.) > See previous mail concerning why I think Server and Timestamp are not applicable. Having reread the bis draft concerning Date, I can see that this is applicable. > Bis says that Record-Route headers MAY be present in a provisional > response, > and doesn't separate out 100 Trying from other 1xx responses. I can > imagine scenarios where Record-Route in a 100 could be useful, but I'm not > sure how plausible they are. > Yes, I can see that the current rules allow a proxy to respond. This would only appear to have any impact on the call from a 1st proxy back to a UAC, as it is only the UAC that sent the request in the first place that can use the accumulated Record-Route information. Now I am stuck to see how useful that usage is. Currently I have a view that 100 Trying need only contain the mandatory headers, plus optionally Date, and I am considering that it would be a simplification of the bis draft to limit it just to that, and separate it out from all the other 1xx responses. Therefore my inclination would be to exclude Record-Route as getting closer to my general treatment of this status-code. > -- > Jonathan Lennox > lennox@cs.columbia.edu > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 12:02:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24927 for ; Fri, 5 Oct 2001 12:02:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12844; Fri, 5 Oct 2001 11:35:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12812 for ; Fri, 5 Oct 2001 11:35:08 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24342 for ; Fri, 5 Oct 2001 11:35:06 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f95FX28P003664; Fri, 5 Oct 2001 11:33:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4KFCA2CA>; Fri, 5 Oct 2001 11:34:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Cc: "'sip-implementors@cs.columbia.edu'" Date: Fri, 5 Oct 2001 11:34:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] DEPRECATION WARNING: Open Issue #206: CR and LF alone Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, My apologies for sending this to sip and sip-implementors, but maximal coverage is needed here. The spec says that implementations MUST send CRLF to terminate lines, but MUST interpret CR or LF by themselves as line terminators, for backwards compatibility. We want to trim as much of this stuff as possible from the spec. So, I ask: is there anyone out there who sends CR or LF alone as line terminators? If so, speak up NOW! Otherwise, we will remove this reuqirement from the spec and ONLY CRLF will be discussed. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 13:19:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26848 for ; Fri, 5 Oct 2001 13:19:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15678; Fri, 5 Oct 2001 12:51:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15646 for ; Fri, 5 Oct 2001 12:51:47 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26251 for ; Fri, 5 Oct 2001 12:51:45 -0400 (EDT) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id f95GpjW06499; Fri, 5 Oct 2001 12:51:45 -0400 From: "Victor Paulsamy" To: Cc: , "Victor Paulsamy" Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Fri, 5 Oct 2001 09:52:11 -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.50.4807.1700 In-Reply-To: <002d01c14d3f$dd530b10$2b01a8c0@broadsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Brett, > > When the UAS is thinking of sending a > > re-INVITE to add a stream, there comes > > a re-INVITE from the UAC without SDP. Can the > > UAS not seize the opportunity to add a stream. > > I find no harm since it makes it consistent with > invite-without-sdp. However if the only benefit > is the saving of 3 messages, it was deemed not > important enough. > The basic offer/answer model has to be up held here. If the UAS were to answer an offer, it must not add a stream. However, here the UAS is offering, wheather or not it is in mid call. >Otherwise we could have allowed > the 200 SDP to contain an answer and offer portion. > > > I'm not seeing the point why it shouldn't be > > added when *all* characteristics of the > > session can be changed. > > Actually *all* characteristics shouldn't be > changed. This was the reason for the open issue. > After receiving a reinvite-without-sdp, the UAS > should attempt to not modify the SDP's existing > media in such a way that would potentially cause > the UAC to have to hold it, delete it, or release > the call. > > Thus most of the time it should return > the previous SDP. Devices that answer hold to > holds should not return the previous SDP > unless it desires to keep the call on hold. > If the UAS were to return the "previous SDP", what purpose does re-INVITE without SDP serve? > Warm regards, --victor _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 13:40:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27209 for ; Fri, 5 Oct 2001 13:40:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16337; Fri, 5 Oct 2001 13:12:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16305 for ; Fri, 5 Oct 2001 13:12:00 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26640 for ; Fri, 5 Oct 2001 13:11:44 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f95HBaL07449; Fri, 5 Oct 2001 19:11:36 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f95HBYL29027; Fri, 5 Oct 2001 20:11:34 +0300 (EET DST) Message-ID: <3BBDE9C6.75A24F0A@lmf.ericsson.se> Date: Fri, 05 Oct 2001 20:11:34 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: stoshniwal@hss.hns.com, sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <65256ADA.0067D2F9.00@sampark.hss.hns.com> <3BBBF18F.BFC292B1@lmf.ericsson.se> <3BBCBF40.3C094992@lmf.ericsson.se> <3BBCD2F0.A675DC45@lmf.ericsson.se> <3BBCDAF0.36E04D75@lmf.ericsson.se> <3BBCD9AA.940E514A@lmf.ericsson.se> <3BBDC8FB.58318192@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>So, when we replace a stream with another that new stream must have the >>SAME codec, the SAME attributes, and the SAME media type, and the ONLY >>thing we are allowed to change is the IP address and/or the port? >If we receive a re-INVITE without SDP (this is the situation we are >talking about) this is true. The SDP in the 2xx will possibly differ >from the SDP currently used only in the port and the IP address. In another mail it was said that the "call-hold" attribute is also allowed to be changed. ...and I then said that in future people may come up with other attributes that also have to be allowed to be changed. Also, we should specify that the port/address thing is for IP sessions only. In ATM it may not be allowed to change the same parameters, for example... >Acutally if you think of the scenario it makes perfectly sense. You are >involved in a session, and you get a re-INVITE. Sonce it is not you the >one re-INVITing, you are not interested in changing anything. Therefore, >it makes sense to return the same SDP that is being used. So, you might >answer, why are we allow to change IP address and port number. Simply >because some frameworks such as Java does not allow you to change the >remote SDP without changing your port number. That is, a new ephemeral >local port number will be assigned to you when you change the remote >SDP. That may be true, and even if I still think that it may cause problems in future I am not going to start arguing against it - as long as we specify that it is IP specific. BUT, I still don't think that means that we should allow a call on hold to be put un-hold - even if that is currently done in SIP by changing the IP address. >I hope this clarifies things. The thing I am worried about is that when we start adding more media attributes (for security, charging and who knows what) there will be a need to also allow to change those in the 200 SDP... Like I said: someone already wrote that we now are allowd to change the IP address and port, AND the call-hold attribute, in the 200 response to a re-INVITE w/o SDP... Regards, Christer Holmberg Ericsson Finland >>Or, once again: are we allowed to change whatever information for a >>stream in a re-INVITE SDP, but only the IP address and/or port in an ACK >>SDP >Yes, you got it. > > Regards, > > Gonzalo > > > > > If that is NOT the case, the propsal of using an attribute for the call > > hold will not work, since we change an attribute for an existing > > stream.... > > > > And, the t.38 fax scenarios won't work, since we replace an audio type > > stream with an image type stream... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Regards, > > > > > > Gonzalo > > > > > > > > > > > For example, the t.38 draft replaces an audio stream with an image (fax) > > > > stream. > > > > > > > > Or, isn't that allowd using the ACK SDP method? > > > > > > > > Also, even if the codec is not changed there may be some stream specific > > > > attributes (can't think of any right now, but they may be defined in > > > > future) added/changed to the ACK SDP, that were not included in the > > > > original SDP, which means the UAS can't send media according to those > > > > sets of attributes. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > Why is this change a big deal for the UAS? > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > Thanks for your comments! > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > > > Columbia University Mobile: +358 40 702 35 35 > > > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > > > New York, NY 10027 > > > > > USA Gonzalo.Camarillo@ericsson.com > > > > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > New York, NY 10027 > > > USA Gonzalo.Camarillo@ericsson.com > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 13:53:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27348 for ; Fri, 5 Oct 2001 13:53:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16630; Fri, 5 Oct 2001 13:28:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16599 for ; Fri, 5 Oct 2001 13:28:48 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26980 for ; Fri, 5 Oct 2001 13:28:47 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f95HSkQ35271; Fri, 5 Oct 2001 13:28:46 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Victor Paulsamy'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Fri, 5 Oct 2001 13:29:00 -0400 Message-ID: <004d01c14dc3$3948fa50$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The basic offer/answer model has to be up > held here. If the UAS were to answer an offer, > it must not add a stream. However, here the UAS is > offering, wheather or not it is in mid call. As I mentioned previously on this thread, I agree that it would make things consistent. http://www1.ietf.org/mail-archive/working-groups/sip/current/msg01161.html > > > I'm not seeing the point why it shouldn't be > > > added when *all* characteristics of the > > > session can be changed. > > > > Actually *all* characteristics shouldn't be > > changed. This was the reason for the open issue. > > After receiving a reinvite-without-sdp, the UAS > > should attempt to not modify the SDP's existing > > media in such a way that would potentially cause > > the UAC to have to hold it, delete it, or release > > the call. > > > > Thus most of the time it should return > > the previous SDP. Devices that answer hold to > > holds should not return the previous SDP > > unless it desires to keep the call on hold. > > > If the UAS were to return the "previous SDP", > what purpose does re-INVITE without SDP serve? It helps to avoid an SDP change loop when a 3PCC/B2BUA unholds the session or switches between lines on behalf of the controlled party. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 14:03:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27593 for ; Fri, 5 Oct 2001 14:03:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17181; Fri, 5 Oct 2001 13:41:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17150 for ; Fri, 5 Oct 2001 13:41:04 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27225 for ; Fri, 5 Oct 2001 13:41:02 -0400 (EDT) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id f95Hf3W16924; Fri, 5 Oct 2001 13:41:03 -0400 From: "Victor Paulsamy" To: Cc: , "Victor Paulsamy" Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Fri, 5 Oct 2001 10:41:29 -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.50.4807.1700 In-Reply-To: <004d01c14dc3$3948fa50$2b01a8c0@broadsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Brett, > > If the UAS were to return the "previous SDP", > > what purpose does re-INVITE without SDP serve? > > It helps to avoid an SDP change loop when > a 3PCC/B2BUA unholds the session or switches > between lines on behalf of the controlled party. > Could you please elaborate it to help understand? Thanks in advance. --victor _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 14:47:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28538 for ; Fri, 5 Oct 2001 14:47:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18597; Fri, 5 Oct 2001 14:23:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18564 for ; Fri, 5 Oct 2001 14:23:55 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28064 for ; Fri, 5 Oct 2001 14:23:53 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f95INre48478; Fri, 5 Oct 2001 14:23:54 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Victor Paulsamy'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Fri, 5 Oct 2001 14:24:08 -0400 Message-ID: <005001c14dca$ed1e4100$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > > If the UAS were to return the "previous SDP", > > > what purpose does re-INVITE without SDP serve? > > > > It helps to avoid an SDP change loop when > > a 3PCC/B2BUA unholds the session or switches > > between lines on behalf of the controlled party. > > > > Could you please elaborate it to help understand? An example of using reinvite-without-sdp is depicted within Figure 9: Mid-Call Announcement of http://www.softarmor.com/sipwg/drafts/draft-rosenberg-sip-3pcc-02.txt Using basic SIP without reinvite-without-sdp, the SDP change loop could have been introduced. The controller would have to send "previous" SDP in a reinvite on behalf of one party. However once that party receives a reinvite, it can change its SDP; thus triggering another invite and potentially a new SDP in response, thus triggering ... sdp change loop. A similar sdp change loop is discussed within section 2.2 of the same draft. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 5 15:00:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28841 for ; Fri, 5 Oct 2001 15:00:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19346; Fri, 5 Oct 2001 14:43:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19317 for ; Fri, 5 Oct 2001 14:43:51 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28513 for ; Fri, 5 Oct 2001 14:43:48 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f95IhlO53573; Fri, 5 Oct 2001 14:43:47 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Christer Holmberg'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Fri, 5 Oct 2001 14:44:02 -0400 Message-ID: <005101c14dcd$b47dc3e0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BBD3CBA.EA099884@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > In future we may have (or maybe there already exist) other similar > attributes, for other services, and then we suddenly may have to allow > those particular attributes to change too... > > For example, someone may come up with some SECURITY related > attributes, > some CHARGING related attributes, some other MEDIA related attributes > (echo canceller, silence supression, etc etc etc), some who-knows-what > attributes, that we must be able to change during the session... I agree. That is why I would prefer the open issue not be closed with "MUST" provide same SDP. I prefer the "SHOULD" text that is currently documented within rfc2543bis-04. It works fine. Everyone agrees that providing modified SDP within the 200 of the 200-ACK model doesn't provide good negotiation capabilities. Thus any product that doesn't provide an SDP offer in 200 that isn't expected to be accepted should be aware that the call will likely be torn down if the rejecting party doesn't "hold" and subsequently send reinvite-with-sdp. > >>I have no problem with what has been > >>agreed, ie that the IP address > >>and/or port can change at any time, > >>but I think that changing from hold > >>to non-hold is a change of STATE > >>(even if SIP currently impelments it > >>using the 0.0.0.0 IP address). > >Correct. And the UAS decides if it wants > >to keep the session on hold or allow it to > >be pulled off hold. > > I think that if the UAS wants to pull off > the hold, it should send an un-hold re-INVITE. I agree; however the UAS only sent hold in response to a hold. Now the UAC is indicating it desires to communicate by sending a reinvite-without-sdp, the UAS should not return hold unless it wishes to keep the media on hold. The UAC will supply hold or non-hold sdp within the ACK; and it potentially will 0 port some of the media streams. (The deleted streams are potentially recoverable based upon another open issue.) _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Oct 6 11:43:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27619 for ; Sat, 6 Oct 2001 11:43:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23354; Sat, 6 Oct 2001 11:08:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23323 for ; Sat, 6 Oct 2001 11:08:32 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27282 for ; Sat, 6 Oct 2001 11:08:24 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f96F8MC08704; Sat, 6 Oct 2001 17:08:22 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f96F8LL27063; Sat, 6 Oct 2001 18:08:21 +0300 (EET DST) Message-ID: <3BBF1E66.666B492C@lmf.ericsson.se> Date: Sat, 06 Oct 2001 18:08:22 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: <005101c14dcd$b47dc3e0$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>In future we may have (or maybe there already exist) other similar >>attributes, for other services, and then we suddenly may have to allow >>those particular attributes to change too... >> >>For example, someone may come up with some SECURITY related >>attributes, some CHARGING related attributes, some other MEDIA related attributes >>(echo canceller, silence supression, etc etc etc), some who-knows-what >>attributes, that we must be able to change during the session... >I agree. That is why I would prefer the open issue not be closed with "MUST" >provide same SDP. I prefer the "SHOULD" text that is currently >documented within rfc2543bis-04. My general opinion is that "SHOULD" makes things even more unclear... >It works fine. Everyone agrees that >providing modified SDP within the 200 of >the 200-ACK model doesn't provide good >negotiation capabilities. Thus any product that >doesn't provide an SDP offer in 200 that >isn't expected to be accepted should be >aware that the call will likely be torn >down if the rejecting party doesn't >"hold" and subsequently send reinvite-with-sdp. > >>>>I have no problem with what has been >>>>agreed, ie that the IP address >>>>and/or port can change at any time, >>>>but I think that changing from hold >>>>to non-hold is a change of STATE >>>>(even if SIP currently impelments it >>>>using the 0.0.0.0 IP address). >>>Correct. And the UAS decides if it wants >>>to keep the session on hold or allow it to >>>be pulled off hold. >> >>I think that if the UAS wants to pull off >>the hold, it should send an un-hold re-INVITE. > >I agree; however the UAS only sent hold in >response to a hold. Well... Someone could argue, that if the UAS is allowed to send un-hold SDP (assuming the session is on hold) to an INVITE w/o SDP it should also be allowed to send a hold SDP (assuming the session is not on hold) to an INVITE w/o SDP... >Now the UAC is indicating it desires to communicate by sending a >reinvite-without-sdp, the UAS should not return hold unless it wishes to keep the media on hold. We should remember that the SDP may include MULTIPLE streams, and maybe SOME of them are on hold, ie the c=0.0.0.0 was sent for specific streams, and not for the whole session. Then, the UAC "desires to communicate", but ONLY with the streams that currently are NOT on hold. It wants the others to remain on hold. >The UAC will supply hold or non-hold sdp within the ACK; and it potentially will 0 port some of >the media streams. (The deleted streams are potentially recoverable based upon another open >issue.) Yes, that is another issue. Assume the UAC has earlier terminated a stream by setting the port to zero. However, since the m= line for that stream must be included in the SDP during the whole session, the UAS could suddenly change the port to non-zero in a 200 response. Do we want to allow that? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Oct 6 17:42:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00683 for ; Sat, 6 Oct 2001 17:42:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00057; Sat, 6 Oct 2001 16:50:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00028 for ; Sat, 6 Oct 2001 16:50:15 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29137 for ; Sat, 6 Oct 2001 16:50:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f96Kmd8P011383 for ; Sat, 6 Oct 2001 16:48:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4KFCAK54>; Sat, 6 Oct 2001 16:49:44 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Sat, 6 Oct 2001 16:49:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] one last update to session timer... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, It was my expectation that draft-ietf-sip-session-timer-07.txt would go to IESG. However, I received a very late private email pointing out a problem in the spec. The problem was this. UAC sends an INVITE with Supported: timer. This goes through some proxies and a UAS, and the result is a Session-Expires in a 200 OKwith a really low value; lower than what the UAC would like. However, since its a 200 OK, a session has been established with that interval. The spec says nothing about how a UAC handles this case; it works fine based on the spec only if the interval is too low for a proxy. In the case of a proxy, the next refresh would have the low session-expires, and would then be rejected by the proxy with a 422, containing a Min-SE with the minimum value. In the case of a UAC, all we need to do is specify that it can increase the value of Min-SE in a refresh. I added a few sentences to that regard. I also moved a few paragraphs around in the section on UAC behavior, just for clarity. draft-ietf-sip-session-timer-08.txt was submitted to the archives today, and should appear shortly (and then head to IESG). Until then, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-session-timer-08.txt -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Oct 7 12:17:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24377 for ; Sun, 7 Oct 2001 12:17:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28604; Sun, 7 Oct 2001 11:46:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28576 for ; Sun, 7 Oct 2001 11:46:49 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24177 for ; Sun, 7 Oct 2001 11:46:45 -0400 (EDT) Received: from jku.iptel.org (dhcp106.fokus.gmd.de [195.37.78.234]) by fox.iptel.org (8.11.6/8.11.2) with ESMTP id f97Fjeu17091; Sun, 7 Oct 2001 17:45:40 +0200 Message-Id: <5.1.0.14.0.20011007173947.034fbeb8@mailhub.fokus.gmd.de> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 07 Oct 2001 17:57:19 +0200 To: Jonathan Rosenberg , "'sip@ietf.org'" From: Jiri Kuthan Subject: Re: [Sip] DEPRECATION WARNING: Open Issue #206: CR and LF alone Cc: "'sip-implementors@cs.columbia.edu'" , sr In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I very much welcome killing CR-only. My execution profiling experience tells that trying to understand all these options may account for up to 20% of CPU time in a stateless proxy (depending mainly on how many characters must be processed which mainly depends on how messages are built by their senders). I have not sighted a non-CR-LF implementation, except debugging messages I send and create on Un*x (LF-only). (Which is not bad from server's parsing performance perspective ... I always seek LF and ignore optional CR.) -Jiri At 05:34 PM 10/5/2001, Jonathan Rosenberg wrote: >Folks, > >My apologies for sending this to sip and sip-implementors, but maximal >coverage is needed here. > >The spec says that implementations MUST send CRLF to terminate lines, but >MUST interpret CR or LF by themselves as line terminators, for backwards >compatibility. We want to trim as much of this stuff as possible from the >spec. So, I ask: is there anyone out there who sends CR or LF alone as line >terminators? If so, speak up NOW! Otherwise, we will remove this reuqirement >from the spec and ONLY CRLF will be discussed. > >-Jonathan R. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 8 11:41:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23981 for ; Mon, 8 Oct 2001 11:41:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06971; Mon, 8 Oct 2001 11:19:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06939 for ; Mon, 8 Oct 2001 11:19:12 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23490 for ; Mon, 8 Oct 2001 11:19:10 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f98FJ5H82770; Mon, 8 Oct 2001 11:19:05 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Jonathan Rosenberg'" , Subject: RE: [Sip] DEPRECATION WARNING: Open Issue #206: CR and LF alone Date: Mon, 8 Oct 2001 11:19:25 -0400 Message-ID: <006701c1500c$9e779030$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The spec says that implementations MUST send CRLF to > terminate lines, but > MUST interpret CR or LF by themselves as line terminators, > for backwards > compatibility. We want to trim as much of this stuff as > possible from the > spec. So, I ask: is there anyone out there who sends CR or LF > alone as line > terminators? If so, speak up NOW! Otherwise, we will remove > this reuqirement > from the spec and ONLY CRLF will be discussed. Does this deprecation also apply to SDP lines? I assume no, but I thought I'd ask. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 9 02:05:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19092 for ; Tue, 9 Oct 2001 02:05:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06490; Tue, 9 Oct 2001 01:40:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06465 for ; Tue, 9 Oct 2001 01:40:41 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12153 for ; Tue, 9 Oct 2001 01:40:39 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f995efC26365 for ; Tue, 9 Oct 2001 07:40:41 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.16]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f995eeL20989 for ; Tue, 9 Oct 2001 08:40:40 +0300 (EET DST) Message-ID: <3BC28DD0.60D98654@lmf.ericsson.se> Date: Tue, 09 Oct 2001 08:40:32 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Via comments Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is related to the CR/LF issue. Since we are on this "trim" issue, I guess we could also ask if anyone puts comments in the Via header (if not, we could maybe get rid of that too...). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 9 07:16:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27358 for ; Tue, 9 Oct 2001 07:16:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14565; Tue, 9 Oct 2001 06:57:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14537 for ; Tue, 9 Oct 2001 06:57:00 -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 GAA27075; Tue, 9 Oct 2001 06:56:55 -0400 (EDT) Message-Id: <200110091056.GAA27075@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 09 Oct 2001 06:56:55 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-08.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-08.txt Pages : 28 Date : 08-Oct-01 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new general headers, Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-session-timer-08.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-session-timer-08.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: <20011008131257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011008131257.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 9 10:11:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03985 for ; Tue, 9 Oct 2001 10:11:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21782; Tue, 9 Oct 2001 09:50:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21749 for ; Tue, 9 Oct 2001 09:50:29 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03147 for ; Tue, 9 Oct 2001 09:50:22 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f99Dmj8P026567; Tue, 9 Oct 2001 09:48:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4QPLK6FG>; Tue, 9 Oct 2001 09:49:51 -0400 Message-ID: From: Jonathan Rosenberg To: "'brett@broadsoft.com'" , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] DEPRECATION WARNING: Open Issue #206: CR and LF alone Date: Tue, 9 Oct 2001 09:49:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Monday, October 08, 2001 11:19 AM > To: 'Jonathan Rosenberg'; sip@ietf.org > Subject: RE: [Sip] DEPRECATION WARNING: Open Issue #206: CR > and LF alone > > > > The spec says that implementations MUST send CRLF to > > terminate lines, but > > MUST interpret CR or LF by themselves as line terminators, > > for backwards > > compatibility. We want to trim as much of this stuff as > > possible from the > > spec. So, I ask: is there anyone out there who sends CR or LF > > alone as line > > terminators? If so, speak up NOW! Otherwise, we will remove > > this reuqirement > > from the spec and ONLY CRLF will be discussed. > > Does this deprecation also apply to SDP lines? > I assume no, but I thought I'd ask. > SDP remains what it is. We are talking about SIP only. In particular, the following sentence: Senders MUST terminate lines with a CRLF, but receivers MUST also interpret CR and LF by themselves as line terminators. Basically, it will now say that senders MUST terminate lines with CRLF, and say nothing on CR and LF by themselves. One of the reasons this was in there initially was the belief that telnet didn't send CRLF, and we wanted to be able to telnet to a SIP server. However, we ran a test on solaris, win2000, and linux, and all three default telnet clients send crlf. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 9 12:19:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07073 for ; Tue, 9 Oct 2001 12:19:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26053; Tue, 9 Oct 2001 11:56:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26023 for ; Tue, 9 Oct 2001 11:56:16 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06455 for ; Tue, 9 Oct 2001 11:56:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f99Fs68P028057; Tue, 9 Oct 2001 11:54:06 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4QPLK6Y3>; Tue, 9 Oct 2001 11:55:11 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Cc: "'sip-implementors@cs.columbia.edu'" Date: Tue, 9 Oct 2001 11:55:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] DEPRECATION WARNING: () comments in Via grammar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, The bis editor team is considering the removal of the use of comments in the Via header. The comment is a paren enclosed text: Via: SIP/2.0/UDP 1.2.3.4 (this is a comment) Before its deprecated, we need to know if anyone is SENDING them (it doesn't matter if your parser can receive them). Please send a note to the authors or the list if you are still sending packets with Via comments. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 9 17:16:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13669 for ; Tue, 9 Oct 2001 17:16:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06955; Tue, 9 Oct 2001 16:55:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06929 for ; Tue, 9 Oct 2001 16:55:46 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13447 for ; Tue, 9 Oct 2001 16:55:39 -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 QAA09147 for ; Tue, 9 Oct 2001 16:55:11 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28061 for ; Tue, 9 Oct 2001 16:55:11 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Oct 2001 16:55:06 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57C34A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" Date: Tue, 9 Oct 2001 16:54:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Help Wanted, automated parse tool users - new SIPbis version Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org As we have announced, we are completely rewriting the sip-bis draft. One of the things we are doing is to extract all the BNF to one section of the document, updating it to be a complete grammar. We would like to test this grammar to make sure it is complete and unambiguous. We have one volunteer who will tell us if the new BNF is good, but my other volunteer has had to cancel out. If you have the ability to turn an ABNF description into a parser, and are willing to run the new grammar through your tools, please send me an email. The first pass of the grammar will be available for this testing tomorrow. I'm especially interested in anyone who can test the grammars for LL(1), as opposed to the LALR that YACC/LEX uses, but I'm not very picky right now. Brian _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 9 22:09:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17812 for ; Tue, 9 Oct 2001 22:09:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17566; Tue, 9 Oct 2001 21:44:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17537 for ; Tue, 9 Oct 2001 21:44:17 -0400 (EDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17594 for ; Tue, 9 Oct 2001 21:44:11 -0400 (EDT) Received: from unknown (HELO rwc-jfmule01.yahoo.com) (208.205.112.130) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Oct 2001 01:44:15 -0000 X-Apparently-From: Message-Id: <5.1.0.14.2.20011009184021.00ad9c30@pop.mail.yahoo.com> X-Sender: jfmule@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Oct 2001 18:43:55 -0700 To: sip@ietf.org, jdrosen@dynamicsoft.com, brett@broadsoft.com From: Jean-Francois Mule Subject: RE: [Sip] YES - DEPRECATION WARNING: Open Issue #206: CR and LF alone Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan Rosenberg wrote > SDP remains what it is. We are talking about SIP only. In > particular, the > following sentence: > > Senders MUST terminate lines with a CRLF, but receivers MUST > also interpret > CR and LF by themselves > as line terminators. > > Basically, it will now say that senders MUST terminate lines > with CRLF, and > say nothing on CR and LF by themselves. I definitely support this change. Based on the last 2 sipit events, there were still quite a few implementations with improper line terminators. Each time we pointed out the requirement that "senders MUST terminate lines with CRLF", they used the argument that "receivers MUST also interpret CR and LF by themselves as line terminators"... No big deal really but this makes the spec more 'authoritative'. Jean-Francois Mule jfmule@yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 10 03:58:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06344 for ; Wed, 10 Oct 2001 03:58:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04756; Wed, 10 Oct 2001 03:43:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04728 for ; Wed, 10 Oct 2001 03:43:33 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06032 for ; Wed, 10 Oct 2001 03:43:31 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9A7hWC04964 for ; Wed, 10 Oct 2001 09:43:32 +0200 (MEST) Received: from ericsson.com (E0080C7779971.lmf.ericsson.se [131.160.30.9]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9A7hVL29425 for ; Wed, 10 Oct 2001 10:43:31 +0300 (EET DST) Message-ID: <3BC3FC21.DF294387@ericsson.com> Date: Wed, 10 Oct 2001 10:43:29 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 3GPP requirements to SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: In the last IETF meeting our Area Director requested 3GPP to write down all the requirements that 3GPP has to SIP. A few people have gathered those requirements and put them into an Internet Draft. The I-D has been recently submitted to the IETF. It might take a few hours to be available in the repositories. In the meantime, you can download the I-D from: http://standards.ericsson.net/sip/drafts/draft-garcia-sipping-3gpp-reqs-00.txt Regards, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 10 11:48:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12693 for ; Wed, 10 Oct 2001 11:48:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19744; Wed, 10 Oct 2001 11:23:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19715 for ; Wed, 10 Oct 2001 11:23:19 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12099 for ; Wed, 10 Oct 2001 11:23:17 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9AFMmV08539 for ; Wed, 10 Oct 2001 11:22:48 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4RZ5L2>; Wed, 10 Oct 2001 16:22:42 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC33E4@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Date: Wed, 10 Oct 2001 14:24:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Sip] privacy draft - use of Remote-party-ID header in methods other th an INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Currently the privacy draft defines the Remote-Party-ID header only for use in the INVITE method. For some other methods, e.g. REGISTER and REFER, it would appear useful to be able to pass other identifiers of the user (in addition to the From and Contact header) between SIP applications. These identifiers are probably much the same as those already covered in the Remote-Party-ID header. What issues would people see in extending the use of the Remote-Party-ID header to a defined set of other methods? Would this be done by extending the privacy draft, or by a new extension altogether, or by some completely new reorganisation of the documentation altogether? Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 10 11:57:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12840 for ; Wed, 10 Oct 2001 11:57:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20569; Wed, 10 Oct 2001 11:42:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20538 for ; Wed, 10 Oct 2001 11:42:18 -0400 (EDT) Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12650 for ; Wed, 10 Oct 2001 11:42:13 -0400 (EDT) Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1]) by mail.net2phone.com (8.11.5/8.11.5) with ESMTP id f9AFfxP27215 for ; Wed, 10 Oct 2001 11:41:59 -0400 (EDT) Received: by mailsvr with Internet Mail Service (5.5.2653.19) id <4M2HMVHZ>; Wed, 10 Oct 2001 11:42:15 -0400 Message-ID: <6F46FABB90ABD411BD690002B3152FB9467077@lkwmail01> From: Romel Khan To: sip@ietf.org Date: Wed, 10 Oct 2001 11:39:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] passing trunk info Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org For accounting purpose, service providers often have the need to obtain the GW Id and Trunk/trunk group that serves a call originated from PSTN. An originating SIP server will have need to pass this information to a SIP application server that does the accounting. Has passing such information (GW Id and Trunk/trunk group) been addressed? _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 10 16:47:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20583 for ; Wed, 10 Oct 2001 16:47:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29976; Wed, 10 Oct 2001 16:18:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29947 for ; Wed, 10 Oct 2001 16:18:20 -0400 (EDT) Received: from pine.il.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19973 for ; Wed, 10 Oct 2001 16:18:16 -0400 (EDT) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.il.neustar.com (8.11.0/8.11.0) with ESMTP id f9AKIIW26624; Wed, 10 Oct 2001 15:18:18 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Oct 2001 15:16:59 -0500 Message-ID: <70565611B164D511957A001083FCDD56478B6D@va02.va.neustar.com> From: "Peterson, Jon" To: "'Romel Khan'" , sip@ietf.org Subject: RE: [Sip] passing trunk info Date: Wed, 10 Oct 2001 15:16:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There does seem to be motivation to support trunk group identifiers within URIs, to designate originating trunk groups and possibly destination trunk groups as well. Requirements for SS7 trunks, PRIs, and even MF trunks have been suggested in the past. The major points of controversy seemed to be the format of the identifier (something broad enough to express any of the above trunk types) and its placement in the message. I would hope, though, that regardless of any problems with designating trunk groups, an identifier for the gateway could be trivially derived from the From header. Maybe the interested parties should kick off a thread on SIPPING (which is probably the appropriate forum for this discussion) to gather requirements for this. Jon Peterson NeuStar, Inc > -----Original Message----- > From: Romel Khan [mailto:rkhan@net2phone.com] > Sent: Wednesday, October 10, 2001 8:40 AM > To: sip@ietf.org > Subject: [Sip] passing trunk info > > > For accounting purpose, service providers often have the need > to obtain the > GW Id and Trunk/trunk group that serves a call originated > from PSTN. An > originating SIP server will have need to pass this > information to a SIP > application server that does the accounting. > Has passing such information (GW Id and Trunk/trunk group) > been addressed? > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 10 16:58:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20799 for ; Wed, 10 Oct 2001 16:58:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00705; Wed, 10 Oct 2001 16:41:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00675 for ; Wed, 10 Oct 2001 16:41:18 -0400 (EDT) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20487 for ; Wed, 10 Oct 2001 16:41:12 -0400 (EDT) Received: (qmail 22399 invoked from network); 10 Oct 2001 20:35:23 -0000 Received: from unknown (HELO overhill) (relay@65.202.222.2) by face.sentitonetworks.com with SMTP; 10 Oct 2001 20:35:23 -0000 From: "Frank W. Miller" To: Subject: FW: [Sip] passing trunk info Date: Wed, 10 Oct 2001 16:39:50 -0400 Message-ID: <000401c151cb$b5b9ace0$c900000a@overhill> 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We are definitely interested in this and have actually started down an implementation path doing something along these lines. In addition, we have been working on a couple of drafts that are aimed at PSTN interoperability. Both provide simplified textual represenations of PSTN protocols, TCAP and the subset of ISUP not covered by the sip-isup draft. Both make use of the SIP INFO message for transport between the SIP UA and a signaling gateway to the PSTN. I will be submitting both of these drafts in the next week or so and am donning my asbestos suit now as a precautionary measure... FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. www.sentito.com -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, October 10, 2001 4:17 PM To: 'Romel Khan'; sip@ietf.org Subject: RE: [Sip] passing trunk info There does seem to be motivation to support trunk group identifiers within URIs, to designate originating trunk groups and possibly destination trunk groups as well. Requirements for SS7 trunks, PRIs, and even MF trunks have been suggested in the past. The major points of controversy seemed to be the format of the identifier (something broad enough to express any of the above trunk types) and its placement in the message. I would hope, though, that regardless of any problems with designating trunk groups, an identifier for the gateway could be trivially derived from the >From header. Maybe the interested parties should kick off a thread on SIPPING (which is probably the appropriate forum for this discussion) to gather requirements for this. Jon Peterson NeuStar, Inc > -----Original Message----- > From: Romel Khan [mailto:rkhan@net2phone.com] > Sent: Wednesday, October 10, 2001 8:40 AM > To: sip@ietf.org > Subject: [Sip] passing trunk info > > > For accounting purpose, service providers often have the need > to obtain the > GW Id and Trunk/trunk group that serves a call originated > from PSTN. An > originating SIP server will have need to pass this > information to a SIP > application server that does the accounting. > Has passing such information (GW Id and Trunk/trunk group) > been addressed? > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 10 21:21:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24093 for ; Wed, 10 Oct 2001 21:21:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07392; Wed, 10 Oct 2001 20:43:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07361 for ; Wed, 10 Oct 2001 20:43:01 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23734 for ; Wed, 10 Oct 2001 20:42:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9B0fN8P012082 for ; Wed, 10 Oct 2001 20:41:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4QPLLBJM>; Wed, 10 Oct 2001 20:42:31 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" Date: Wed, 10 Oct 2001 20:42:29 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-manyfolks -resource-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dear SIP WG Members, The subject draft (link below) is going through WGLC. The assigned reviewers have or should be posting their initial comments on the list. The Last Call Open Discussion will be closed on 12Nov01. Please post your comments to the list. The authors will be collecting this input and addressing issues. The authors will post a summary at the end of this part of the last call process. If you have any further questions, please feel free to contact me. Links Draft - http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-manyfolks-resource-02.t xt Last Call Calendar - http://www.softarmor.com/sipwg/lastcall/lccalendar.pl Reviewer's page - http://www.softarmor.com/sipwg/lastcall/reviewerinfo.html Supplemental SIP WG Web site - http://www.softarmor.com/sipwg Regards, Rakesh ______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 (973) 952-5000 main (973) 952-5066 direct (201) 214-6084 mobile (973) 952-5050 fax rshah@dynamicsoft.com www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 10 22:03:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25619 for ; Wed, 10 Oct 2001 22:03:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08909; Wed, 10 Oct 2001 21:33:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08882 for ; Wed, 10 Oct 2001 21:33:57 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24221 for ; Wed, 10 Oct 2001 21:33:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9B1WK8P012253 for ; Wed, 10 Oct 2001 21:32:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4QPLLBLQ>; Wed, 10 Oct 2001 21:33:27 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" Subject: [Sip] SIP WG - Last Call Weekly Status Update Date: Wed, 10 Oct 2001 21:33:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dear SIP Working Group Members, This Working Group Last Call status is being sent out to keep you up-to-speed. Any questions about this information can be addressed to Rakesh Shah (mailto:rshah@dynamicsoft.com). Drafts in WGLC draft-ietf-sip-serverfeatures-05.txt Awaiting comments from A. Mankin. WGLC completed. Draft was submitted to IESG, returned for updates and updates were made by authors. The draft was then passed on to AD for IESG submittal. draft-ietf-sip-session-timer-08.txt WGLC complete. Submitting to IESG. draft-ietf-sip-callerprefs-04.txt Last Call review completed. Waiting for authors' summary. Summary delayed due to bis re-write. draft-ietf-sip-mib-03.txt LC review started. Checking with reviewers to see if they are done. List discussion is open, but there has been no activity. draft-ietf-sip-manyfolks-resource-02.txt Open discussion announced. (Critical to 3GPP.) draft-ietf-sip-call-auth-02.txt LC review started. Checking with reviewers to see where they are. Will start open list discussion when it is clear that the reviewers are done. (Critical for 3GPP.) draft-ietf-sip-state-02.txt Contacting NITS reviewer. Queued up after call-auth. Drafts Queued for WGLC draft-johnston-sip-osp-token-01.txt Progressing to WGLC. draft-ietf-sip-100rel-03.txt Feedback expected from A. Mankin. Dependency on "supported" (serverfeatures). This information is kept up-to-date on the supplemental SIP WG Web site (link below). Links Last Call Calendar - http://www.softarmor.com/sipwg/lastcall/lccalendar.pl Supplemental SIP WG Web site - http://www.softarmor.com/sipwg Regards, Rakesh ______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 (973) 952-5000 main (973) 952-5066 direct (201) 214-6084 mobile (973) 952-5050 fax rshah@dynamicsoft.com www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 04:41:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13568 for ; Thu, 11 Oct 2001 04:41:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27139; Thu, 11 Oct 2001 04:17:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27109 for ; Thu, 11 Oct 2001 04:17:32 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13454 for ; Thu, 11 Oct 2001 04:17:30 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9B8HMC11899; Thu, 11 Oct 2001 10:17:22 +0200 (MEST) Received: from ericsson.com (E0080C7779971.lmf.ericsson.se [131.160.30.9]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9B8HJL05181; Thu, 11 Oct 2001 11:17:20 +0300 (EET DST) Message-ID: <3BC5558D.B60BA0B@ericsson.com> Date: Thu, 11 Oct 2001 11:17:17 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org CC: Keith Drage , William Marshall Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SDP in 200 OK for INVITE and preconditions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: I would like to get some advice on an issue that has been recently pointed out. The 2543bis says clearly that the 200 OK for an INVITE must contain SDP. SDP is present in INVITE and 200 OK or in 200 OK and ACK, but always in 200 OK. However, if preconditions are used (manyfolks), the SDP is already known by both parties before the 200 OK, usually in INVITE and 183. As such, one may think if the SDP is still needed in 200 OK for the INVITE when preconditions are used. I checked out the manyfolks draft, and currently it is stated that the 200 OK for the INVITE is a "normal" one. By "normal" one I understand that it must contain SDP. Therefore, I understand that from the SIP perspective, the SDP in the 200 OK does not contain any new information, and as such, one could think of saving a few bytes there (not so much if compression is used, but anyway). But I believe the SDP is strictly needed, as the signaling may have traversed a few proxies that depend on the SDP in the 200 OK for whatever reasons (opening holes in a firewall or whatever). I would like to clarify if the SDP in the 200 OK for an INVITE is needed when preconditions are used. And I would like to identify scenarios where it might be needed. In case the SDP is needed, perhaps the manyfolks draft could put a little bit of emphasis on this aspect. It would be nice to clarify also that the SDP in the 200 OK cannot be used to change the already agreed preconditions (otherwise the whole precondition negotiation is sent to the trash can). /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 08:29:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15136 for ; Thu, 11 Oct 2001 08:29:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03489; Thu, 11 Oct 2001 08:15:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03461 for ; Thu, 11 Oct 2001 08:14:58 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14992 for ; Thu, 11 Oct 2001 08:14:56 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 11 Oct 2001 12:15:00 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 11 Oct 2001 13:15:16 +0100 From: "James Undery" To: "William Marshall" , Subject: RE: [Sip] SDP in 200 OK for INVITE and preconditions Date: Thu, 11 Oct 2001 13:14: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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <200110111206.IAA17960@fish.research.att.com> X-OriginalArrivalTime: 11 Oct 2001 12:15:16.0373 (UTC) FILETIME=[62ED4C50:01C1524E] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of William > Marshall > Sent: 11 October 2001 13:07 > To: sip@ietf.org > Subject: Re: [Sip] SDP in 200 OK for INVITE and preconditions > > > There is an issue here with document dependencies, and I really > don't want manyfolks to have a dependency on bis... As I said in my last call comment I believe it does, because it mentions Record Route which never worked (or was even implemented properly) to my knowledge. James > RFC2543 essentially allows SDP anywhere, which led to the > bis wording. > But in the end, I believe the following is the resulting set of > MUSTs and options for SDP with manyfolks+bis: > > case 1: SDP in INVITE > SDP in 183 > optional SDP in PRACK > SDP in COMET (if COMET is requested) > SDP in 200 > > case 2: SDP in 183 > SDP in PRACK > SDP in COMET (if COMET is requested) > SDP in 200 > SDP in ACK > > The need for the SDP in case#1 in the 200-OK was discussed on the > last earlier this year, and concluded to keep it. Though the > SDP in 200/ACK in case#2 wasn't discussed, the reasoning seems > the same - uniformity with cases that don't use manyfolks. > > I agree that some wording should be added to manyfolks to relate > the SDP in the 200 to the SDP in 183. Likewise for case#2, the > SDP in ACK needs to be related to the SDP in PRACK. > > Bill Marshall > wtm@research.att.com > > -----original message----- > Date: Thu, 11 Oct 2001 11:17:17 +0300 > From: "Miguel A. Garcia" > To: sip@ietf.org > Subject: SDP in 200 OK for INVITE and preconditions > > Hi: > > I would like to get some advice on an issue that has been > recently pointed out. > > The 2543bis says clearly that the 200 OK for an INVITE must > contain SDP. SDP is present in INVITE and 200 OK or in 200 > OK and ACK, but always in 200 OK. > > However, if preconditions are used (manyfolks), the SDP is > already known by both parties before the 200 OK, usually in > INVITE and 183. As such, one may think if the SDP is still > needed in 200 OK for the INVITE when preconditions are used. > > I checked out the manyfolks draft, and currently it is > stated that the 200 OK for the INVITE is a "normal" one. By > "normal" one I understand that it must contain SDP. > > needed, as the signaling may have traversed a few proxies > that depend on the SDP in the 200 OK for whatever reasons > (opening holes in a firewall or whatever). > > I would like to clarify if the SDP in the 200 OK for an > INVITE is needed when preconditions are used. And I would > like to identify scenarios where it might be needed. > > n negotiation is sent to the trash can). > > /Miguel > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 08:46:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15301 for ; Thu, 11 Oct 2001 08:46:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03811; Thu, 11 Oct 2001 08:30:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03766 for ; Thu, 11 Oct 2001 08:30:12 -0400 (EDT) Received: from isochrone.com (www.isochrone.com [12.32.246.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15182 for ; Thu, 11 Oct 2001 08:30:10 -0400 (EDT) Date: Thu, 11 Oct 2001 08:30:59 -0400 Message-Id: <200110110830.AA1217921408@isochrone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Ram Mohan" Reply-To: To: X-Mailer: Subject: [Sip] Mid Call Announcements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I am in need to make mid call Announcements between two Sip User Agents.I am going to use an SIP Proxy Server and an Media Server. Can anyone help me out with the basic call flows. Thanks in advance, Regards, Rammohan. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 08:54:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15404 for ; Thu, 11 Oct 2001 08:54:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04118; Thu, 11 Oct 2001 08:35:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04087 for ; Thu, 11 Oct 2001 08:35:10 -0400 (EDT) Received: from commserver.iperia.com ([63.84.167.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15213 for ; Thu, 11 Oct 2001 08:35:08 -0400 (EDT) Received: by COMMSERVER with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Oct 2001 08:35:46 -0400 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F61847AF@COMMSERVER> From: Steve Gardell To: sip@ietf.org Subject: RE: [Sip] Mid Call Announcements Date: Thu, 11 Oct 2001 08:35:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I would first to draft-rosenberg-sip-3pcc-02.txt > -----Original Message----- > From: Ram Mohan [mailto:rammohan@isochrone.com] > Sent: Thursday, October 11, 2001 8:31 AM > To: sip@ietf.org > Subject: [Sip] Mid Call Announcements > > > Hi, > I am in need to make mid call Announcements between two Sip > User Agents.I am going to use an SIP Proxy Server and an Media Server. > Can anyone help me out with the basic call flows. > Thanks in advance, > Regards, > Rammohan. > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 09:03:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15676 for ; Thu, 11 Oct 2001 09:03:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03384; Thu, 11 Oct 2001 08:07:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03353 for ; Thu, 11 Oct 2001 08:07:57 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14956 for ; Thu, 11 Oct 2001 08:07:55 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 447971E043; Thu, 11 Oct 2001 08:07:57 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA20117; Thu, 11 Oct 2001 08:07:56 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA17960; Thu, 11 Oct 2001 08:06:51 -0400 (EDT) Date: Thu, 11 Oct 2001 08:06:51 -0400 (EDT) Message-Id: <200110111206.IAA17960@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] SDP in 200 OK for INVITE and preconditions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There is an issue here with document dependencies, and I really don't want manyfolks to have a dependency on bis... RFC2543 essentially allows SDP anywhere, which led to the bis wording. But in the end, I believe the following is the resulting set of MUSTs and options for SDP with manyfolks+bis: case 1: SDP in INVITE SDP in 183 optional SDP in PRACK SDP in COMET (if COMET is requested) SDP in 200 case 2: SDP in 183 SDP in PRACK SDP in COMET (if COMET is requested) SDP in 200 SDP in ACK The need for the SDP in case#1 in the 200-OK was discussed on the last earlier this year, and concluded to keep it. Though the SDP in 200/ACK in case#2 wasn't discussed, the reasoning seems the same - uniformity with cases that don't use manyfolks. I agree that some wording should be added to manyfolks to relate the SDP in the 200 to the SDP in 183. Likewise for case#2, the SDP in ACK needs to be related to the SDP in PRACK. Bill Marshall wtm@research.att.com -----original message----- Date: Thu, 11 Oct 2001 11:17:17 +0300 From: "Miguel A. Garcia" To: sip@ietf.org Subject: SDP in 200 OK for INVITE and preconditions Hi: I would like to get some advice on an issue that has been recently pointed out. The 2543bis says clearly that the 200 OK for an INVITE must contain SDP. SDP is present in INVITE and 200 OK or in 200 OK and ACK, but always in 200 OK. However, if preconditions are used (manyfolks), the SDP is already known by both parties before the 200 OK, usually in INVITE and 183. As such, one may think if the SDP is still needed in 200 OK for the INVITE when preconditions are used. I checked out the manyfolks draft, and currently it is stated that the 200 OK for the INVITE is a "normal" one. By "normal" one I understand that it must contain SDP. needed, as the signaling may have traversed a few proxies that depend on the SDP in the 200 OK for whatever reasons (opening holes in a firewall or whatever). I would like to clarify if the SDP in the 200 OK for an INVITE is needed when preconditions are used. And I would like to identify scenarios where it might be needed. n negotiation is sent to the trash can). /Miguel _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 09:42:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16264 for ; Thu, 11 Oct 2001 09:42:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05793; Thu, 11 Oct 2001 09:23:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05761 for ; Thu, 11 Oct 2001 09:23:13 -0400 (EDT) Received: from isochrone.com (www.isochrone.com [12.32.246.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15872 for ; Thu, 11 Oct 2001 09:23:12 -0400 (EDT) Date: Thu, 11 Oct 2001 09:24:01 -0400 Message-Id: <200110110924.AA1230700928@isochrone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Ram Mohan" Reply-To: To: CC: X-Mailer: Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Is there any other method without involving the ThirParty Call Controller. Regards, Rammohan. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 09:48:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16438 for ; Thu, 11 Oct 2001 09:48:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05944; Thu, 11 Oct 2001 09:27:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05906 for ; Thu, 11 Oct 2001 09:27:09 -0400 (EDT) Received: from commserver.iperia.com ([63.84.167.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15932 for ; Thu, 11 Oct 2001 09:27:09 -0400 (EDT) Received: by COMMSERVER with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Oct 2001 09:28:26 -0400 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F61847B0@COMMSERVER> From: Steve Gardell To: "'rammohan@isochrone.com'" , Steve Gardell Cc: sip@ietf.org Date: Thu, 11 Oct 2001 09:28:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I believe that any other method will require extensions to UA/UC's beyond "basic SIP", but no doubt there are people on the list who can speak more authoritatively to this than I. > -----Original Message----- > From: Ram Mohan [mailto:rammohan@isochrone.com] > Sent: Thursday, October 11, 2001 9:24 AM > To: sgardell@iperia.com > Cc: sip@ietf.org > Subject: > > > Hi, > Is there any other method without involving the ThirParty > Call Controller. > Regards, > Rammohan. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 09:58:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16574 for ; Thu, 11 Oct 2001 09:58:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05581; Thu, 11 Oct 2001 09:17:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05524 for ; Thu, 11 Oct 2001 09:17:56 -0400 (EDT) Received: from isochrone.com (www.isochrone.com [12.32.246.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15814; Thu, 11 Oct 2001 09:17:55 -0400 (EDT) Date: Thu, 11 Oct 2001 09:18:46 -0400 Message-Id: <200110110918.AA450953632@isochrone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Ram Mohan" Reply-To: To: CC: X-Mailer: Subject: [Sip] Re: Welcome To "Sip"! (Digest mode) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I need to make an mid call announcement during call setuo between two USER AGENTS.HOw do i do that? using an Proxewy Server and an Media Server.I would be greatfullif anyone could guide me through any call flow fullfilling my requirements. Thanks in Advance, Regards, Rammohan. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 13:09:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20120 for ; Thu, 11 Oct 2001 13:09:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14230; Thu, 11 Oct 2001 12:53:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14203 for ; Thu, 11 Oct 2001 12:53:11 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19767 for ; Thu, 11 Oct 2001 12:53:09 -0400 (EDT) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id LAA26756 for ; Thu, 11 Oct 2001 11:58:44 -0500 Received: from bculpepperpc ([151.214.151.122]) by 172.16.16.64; Thu, 11 Oct 2001 11:52:21 -0500 From: "Bert Culpepper" To: "'SIP List'" Cc: "'Rakesh Shah'" Date: Thu, 11 Oct 2001 12:52:09 -0400 Message-ID: <001601c15275$11a28780$7a97d697@orlando.brite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Sip] Last Call Review - draft-ietf-sip-call-auth-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't claim knowledge in the area of network bandwidth reservation, however I do have one comment on the document... For the sake of completeness, and since it defines a new header, shouldn't it contain information on (a row) its usage for Table 4/5 in RFC 2543? Otherwise the document looks OK to me. Regards, Bert _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 13:58:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21292 for ; Thu, 11 Oct 2001 13:58:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15861; Thu, 11 Oct 2001 13:36:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15830 for ; Thu, 11 Oct 2001 13:36:56 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20728 for ; Thu, 11 Oct 2001 13:36:55 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 3804A1E02B; Thu, 11 Oct 2001 13:36:58 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA28093; Thu, 11 Oct 2001 13:36:53 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id NAA35414; Thu, 11 Oct 2001 13:36:25 -0400 (EDT) Date: Thu, 11 Oct 2001 13:36:25 -0400 (EDT) Message-Id: <200110111736.NAA35414@fish.research.att.com> To: sip@ietf.org Cc: jundery@ubiquity.net Subject: RE: [Sip] SDP in 200 OK for INVITE and preconditions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org James, Perhaps I passed over your comment too quickly in updating the draft last month. The quick answer is that the manyfolks draft took the exact wording from 100rel, which had the same issue and has passed WGLC and is in the IESG queue. It is certainly true that any working SIP implementation needs to follow the revised rules for Record-Route given in bis. However, the headers are defined in 2543 and (somewhat incomplete and/or incorrect) rules for their use are given in 2543. My intent in the manyfolks draft is to not contradict any of the new bis procedures, and to specify the minimum of corrections to 2543 procedures. In this way any implementation true to 2543, when extended with the manyfolks-resource procedures, will work as well as it did before, and do resource reservation too. An implementation that is tracking 2543bis, when extended with the manyfolks-resource procecures, will not have to deal with any conflicting MUSTs. And it will work. I certainly recognize this is a compromise position, and wish the timing had worked out better. However, the end state of bis+manyfolks is a complete and correct specification. Bill Marshall wtm@research.att.com -----original message----- From: "James Undery" To: "William Marshall" , Subject: RE: [Sip] SDP in 200 OK for INVITE and preconditions Date: Thu, 11 Oct 2001 13:14:30 +0100 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of William Marshall > Sent: 11 October 2001 13:07 > To: sip@ietf.org > Subject: Re: [Sip] SDP in 200 OK for INVITE and preconditions > > > There is an issue here with document dependencies, and I really > don't want manyfolks to have a dependency on bis... As I said in my last call comment I believe it does, because it mentions Record Route which never worked (or was even implemented properly) to my knowledge. James _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 17:53:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26468 for ; Thu, 11 Oct 2001 17:53:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22322; Thu, 11 Oct 2001 17:26:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22293 for ; Thu, 11 Oct 2001 17:26:47 -0400 (EDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25933 for ; Thu, 11 Oct 2001 17:26:45 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f9BLQnN15600; Thu, 11 Oct 2001 17:26:49 -0400 (EDT) Reply-To: From: "Eric Burger" To: "SIP List" Cc: "Rakesh Shah" , Date: Thu, 11 Oct 2001 17:28:41 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Sip] RE: draft-ietf-sip-call-auth-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit NITS Review: Other than what Mary & Bert had to say... p. 4 (6.1.1), last paragraph, needs some commas: "The PDP-o stores the authorized Media description in its local store, generates an Authorization-Token that points to this description, and returns the Authorization-Token to the OP." p.12 (9): What online list of claimed rights? http://www.ietf.org/ipr.html doesn't list anything pertaining to this draft. General: The draft explains the happy path (paths get opened). However, it doesn't really ever touch upon the unhappy path (no authorization, ABR only, etc.). Some unhappy path examples would probably help. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 11 19:13:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28318 for ; Thu, 11 Oct 2001 19:13:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24465; Thu, 11 Oct 2001 18:42:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24433 for ; Thu, 11 Oct 2001 18:42:51 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27855 for ; Thu, 11 Oct 2001 18:42:49 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9BMfjS24416 for ; Thu, 11 Oct 2001 18:41:45 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 11 Oct 2001 18:42:01 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4SX6RQS9>; Thu, 11 Oct 2001 18:41:44 -0400 Message-ID: <28560036253BD41191A10000F8BCBD1105848226@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: sip@ietf.org Cc: "'klingle@cisco.com'" , "'jmaeng@ipdialog.com'" , "'jfm@clarent.com'" , "'drwalker@ss8.com'" Date: Thu, 11 Oct 2001 18:41:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C152A5.E5DB71D0" X-Orig: Subject: [Sip] Review of draft-ietf-sip-mib-03.txt Part 2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C152A5.E5DB71D0 Content-Type: text/plain; charset="iso-8859-1" Further comments ================ SIP-COMMON-MIB (cont'd) A further remark on sipInviteTimeout: in principle we need an application-level timeout value for each method, not just INVITE. We might possibly get away with one for initial INVITE and one for all other requests. Clearly the expected turnaround for a REGISTER will be different from that for a PRACK, but both of them should finish in a few seconds at most rather than the minutes an initial INVITE could take. I will again question whether application-level timers belong in SIP-COMMON-MIB or in SIP-UA-MIB. sipMethodStatsEntry: INFO method should be treated like all other extensions, rather than appear explicitly in this table. sipSummaryTotalTransactions: description should indicate what a transaction stateless proxy does with this counter (probably leaves it at 0). sipStatsInfoIns, Outs: shouldn't be given special treatment -- belong in the sipStatsExtMethodTable with all the other method extensions. SipStatusCodesEntry: should "other" class entries be defined, for status codes 700 and up? sipStatsRedirClassIns, Outs: 3xx responses don't necessarily come from Redirect Servers -- UAs could be set up to forward calls, for instance. Hence the phrase "taken by a Redirect Server" in the description is inappropriate. sipStatsServerFailClassIns, Outs: final sentence of description defines SIP protocol behaviour, not SNMP Agent behaviour, hence should be omitted. sipStatsGlobalFailClassIns, Outs: ditto sipStatsExtMethodStatus: description is a bit sparse. Would something more along the lines of the description for sipCommonStatusCodeStatus not be desirable here too? sipStatusCodeNotifTo, From, CallId, CSeq: do the reported values include the header keywords themselves, or only the part following the colon? (e.g.) "From:xx..x" vs. "xx..x" sipCurrentTransTable: need something be said about transaction stateless proxies? sipCurrentTransEntry: typo in description -- should be "entity's" rather than "entities'". SipTransactionEntry: need an object identifying the method which initiated the transaction. sipTransTo, From, CallId, CSeq: do the reported values include the header keywords themselves, or only the part following the colon? (e.g.) "From:xx..x" vs. "xx..x" sipTransState: most of these states apply only to INVITE transactions, and some of them (null, completed, confirmed) do not apply to transactions currently in process. I would suggest instead capturing the latest activity in the transaction. This has two parts: direction (received/sent) and status code value or request (the latter being either the initiating request or ACK). sipTransExpiry: behaviour will be affected by the outcome of my initial remark on sipInviteTimeout. sipTransCallingPartyContentType, sipTransCalledPartyContentType: nice try, but it doesn't work. Content type varies from message to message within a transaction. Perhaps these objects could record the aggregation of content types over all messages so far passed in the transaction -- that would reflect your intent. SipCommonStatsRetryEntry: as with sipMethodStatsEntry, the INFO method should be treated like all other extensions, rather than appear explicitly in this table. sipOtherStatsEntry: typo in description -- should be "entity's" rather than "entities'". sipNotifApplIndex: doesn't point to the actual status code being monitored. Shouldn't it be the same structure as the index of sipCommonStatusCodeTable? SIP-UA-MIB ========== General comment on configuration: should there be a requirement to populate the SIP-COMMON-MIB data for each entity before populating this MIB? How is this expressed? sipUAMIBNotifs is empty. Where is the definition of sipUAStats?? sipUACfgSipServerEntry: should say that applIndex for each entity instance has the same value as used for that instance in the tables of SIP-COMMON-MIB. Might it be desirable to configure the UA's Contact address? SIP-SERVER-MIB ============== General comment on configuration: should there be a requirement to populate the SIP-COMMON-MIB data for each entity before populating this MIB? How is this expressed? sipServerMIB: description has definitions of the different server types. Would it be safer to refer to the RFC instead? In any event, a Proxy does not initiate requests (as indicated in the definition of a Redirect Server). It does propagate them. sipServerCfgEntry: should say that applIndex for each instance has the same value as in SIP-COMMON-MIB. Question: should there be a RowStatus object? Can values be changed on the fly? SipProxyCfgEntry: should there be a RowStatus object? SipRegCfgEntry: ditto sipContactPreference: typed as an OCTET STRING. Couldn't that be an IA5String, or is that not allowed in SNMP? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C152A5.E5DB71D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-sip-mib-03.txt Part 2

Further comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
SIP-COMMON-MIB (cont'd)

A further remark on sipInviteTimeout: in principle we = need an application-level timeout value for each method, not just = INVITE.  We might possibly get away with one for initial INVITE = and one for all other requests.  Clearly the expected turnaround = for a REGISTER will be different from that for a PRACK, but both of = them should finish in a few seconds at most rather than the minutes an = initial INVITE could take.  I will again question whether = application-level timers belong in SIP-COMMON-MIB or in = SIP-UA-MIB.

sipMethodStatsEntry: INFO method should be treated = like all other extensions, rather than appear explicitly in this = table.

sipSummaryTotalTransactions: description should = indicate what a transaction stateless proxy does with this counter = (probably leaves it at 0).

sipStatsInfoIns, Outs: shouldn't be given special = treatment -- belong in the sipStatsExtMethodTable with all the other = method extensions.

SipStatusCodesEntry: should "other" class = entries be defined, for status codes 700 and up?

sipStatsRedirClassIns, Outs: 3xx responses don't = necessarily come from Redirect Servers -- UAs could be set up to = forward calls, for instance.  Hence the phrase "taken by a = Redirect Server" in the description is inappropriate.

sipStatsServerFailClassIns, Outs: final sentence of = description defines SIP protocol behaviour, not SNMP Agent behaviour, = hence should be omitted.

sipStatsGlobalFailClassIns, Outs: ditto

sipStatsExtMethodStatus: description is a bit = sparse.  Would something more along the lines of the description = for sipCommonStatusCodeStatus not be desirable here too?

sipStatusCodeNotifTo, From, CallId, CSeq: do the = reported values include the header keywords themselves, or only the = part following the colon? (e.g.) "From:xx..x" vs. = "xx..x"

sipCurrentTransTable: need something be said about = transaction stateless proxies?

sipCurrentTransEntry: typo in description -- should = be "entity's" rather than "entities'".  =

SipTransactionEntry: need an object identifying the = method which initiated the transaction.

sipTransTo, From, CallId, CSeq: do the reported = values include the header keywords themselves, or only the part = following the colon? (e.g.) "From:xx..x" vs. = "xx..x"

sipTransState: most of these states apply only to = INVITE transactions, and  some of them (null, completed, = confirmed) do not apply to transactions currently in process.  I = would suggest instead capturing the latest activity in the = transaction.  This has two parts: direction (received/sent) and = status code value or request (the latter being either the initiating = request or ACK).

sipTransExpiry: behaviour will be affected by the = outcome of my initial remark on sipInviteTimeout.

sipTransCallingPartyContentType, = sipTransCalledPartyContentType: nice try, but it doesn't work.  = Content type varies from message to message within a transaction.  = Perhaps these objects could record the aggregation of content types = over all messages so far passed in the transaction -- that would = reflect your intent.

 
SipCommonStatsRetryEntry: as with = sipMethodStatsEntry, the INFO method should be treated like all other = extensions, rather than appear explicitly in this table.

sipOtherStatsEntry: typo in description -- should be = "entity's" rather than "entities'".

sipNotifApplIndex: doesn't point to the actual status = code being monitored.  Shouldn't it be the same structure as the = index of sipCommonStatusCodeTable?

SIP-UA-MIB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

General comment on configuration: should there be a = requirement to populate the SIP-COMMON-MIB data for each entity before = populating this MIB?  How is this expressed?

sipUAMIBNotifs is empty.

Where is the definition of sipUAStats??

sipUACfgSipServerEntry: should say that applIndex for = each entity instance has the same value as used for that instance in = the tables of SIP-COMMON-MIB.

Might it be desirable to configure the UA's Contact = address?

SIP-SERVER-MIB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

General comment on configuration: should there be a = requirement to populate the SIP-COMMON-MIB data for each entity before = populating this MIB?  How is this expressed?

sipServerMIB: description has definitions of the = different server types.  Would it be safer to refer to the RFC = instead?  In any event, a Proxy does not initiate requests (as = indicated in the definition of a Redirect Server).  It does = propagate them.

sipServerCfgEntry: should say that applIndex for each = instance has the same value as in SIP-COMMON-MIB.  Question: = should there be a RowStatus object?  Can values be changed on the = fly?

SipProxyCfgEntry: should there be a RowStatus = object?

SipRegCfgEntry: ditto

sipContactPreference: typed as an OCTET STRING.  = Couldn't that be an IA5String, or is that not allowed in SNMP?




 

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C152A5.E5DB71D0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 12 01:45:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06902 for ; Fri, 12 Oct 2001 01:45:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10190; Fri, 12 Oct 2001 01:18:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10162 for ; Fri, 12 Oct 2001 01:18:11 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05313 for ; Fri, 12 Oct 2001 01:18:09 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9C5IAL16223 for ; Fri, 12 Oct 2001 07:18:10 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9C5I9L02914 for ; Fri, 12 Oct 2001 08:18:09 +0300 (EET DST) Message-ID: <3BC67D10.20E1A02C@lmf.ericsson.se> Date: Fri, 12 Oct 2001 08:18:08 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] manyfolks and RFC2543 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, In another thread it has been mentioned that the manyfolks draft should not be "bis dependent", and the rules for Record-Routing was given as one example. I don't know how important it is, but there are others too. For example, manyfolks says that one may CANCEL a COMET, but I think the current status is that we won't allow that, right? Also, it says that one can terminate a call leg using CANCEL, but that doesn't take forking environments into account, where we have decided that BYE must be used (if we don't want to terminate the WHOLE call setup, that is). Just a few comments... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 12 04:45:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20626 for ; Fri, 12 Oct 2001 04:45:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14314; Fri, 12 Oct 2001 03:57:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14283 for ; Fri, 12 Oct 2001 03:57:52 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20297 for ; Fri, 12 Oct 2001 03:57:47 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9C7vXC18865 for ; Fri, 12 Oct 2001 09:57:33 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9C7vWL08792 for ; Fri, 12 Oct 2001 10:57:32 +0300 (EET DST) Message-ID: <3BC6A269.85E7157E@lmf.ericsson.se> Date: Fri, 12 Oct 2001 10:57:29 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] m= lines with multiple ports Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, More on the SIP media handling discussion. At the moment, I think most people agree that the number of m= lines in the request and response MUST match. Now, SDP allows the including of multiple ports (so called port pairs) in a single m= line, so the UAC may send: m=audio 2000/2 RTP/AVP 31 Now, there are a few scenarios: 1. The UAS only supports the stream on one port. In that case, it could indicate that by sending: m=audio 3000 RTP/AVP 31 m=audio 0 RTP/AVP 31 However, this breaks the matching rule... 2. The UAS supports both streams, but can not use a port pair for them, so again it must use separate m= lines, by sending: m=audio 3000 RTP/AVP 31 m=audio 4000 RTP/AVP 31 However, this breaks the matching rule... 3. The UAS doesn't accept this at all, by sending: m=audio 0 RTP/AVP 31 ...or, should it send: m=audio 0/0 RTP/AVP 31 This does match the rule. I don't know how often this would happend in SIP, but since SDP allows it it MAY happend. The question is: shall we forbid that kind of SDP use in SIP, or how shall we handle it? SDP also allows us to have a c= line indicating multiple IP addresses, which makes this even more complicated. However, in that case we are talking about multicasting, so let's forget about that for now. Regards, Christer Holmberg Ercisson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 12 20:18:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11871 for ; Fri, 12 Oct 2001 20:18:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14054; Fri, 12 Oct 2001 19:49:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14020 for ; Fri, 12 Oct 2001 19:48:55 -0400 (EDT) Received: from rwcxch01.clarent.com ([208.205.112.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11476 for ; Fri, 12 Oct 2001 19:48:50 -0400 (EDT) Received: by rwcxch01.clarent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Oct 2001 16:55:28 -0700 Received: from rwcjfmule01 (adsl-64-169-17-213.dsl.snfc21.pacbell.net [64.169.17.213]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TYCRHAG0; Fri, 12 Oct 2001 16:46:27 -0700 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: sip@ietf.org, "'Tom-PT Taylor'" Cc: "'Kevin Lingle'" , "'Joon Maeng '" , "'Dave Walker '" Date: Fri, 12 Oct 2001 16:47:11 -0700 Message-ID: <002101c15378$36db09b0$d511a940@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] sip-mib: rewrite of Admin and Oper status objects Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is an update based on Tom Taylor's comments as well as other threads on the sip-mib yahoo group. We believe it addresses the comments received to date on these sip mib status objects. Jean-Francois Mule -- My opinions are my own and do not reflect the ones of my current employer ----------------------------------------------------------- -- New definition proposal based on sip-mib discussions -- and comments received from Tom Taylor on 10/1/2001 -- to realign this with applOperStatus sipServiceOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), congested(3), restarting(4), quiescing(5), testing(6), unknown(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the current operational state of the SIP application. up(1) : The application is operating normally, and is processing (receiving and possibly issuing) SIP requests and responses. down(2) : The application is currently unable to process SIP messages. congested(3) : The application is operational but no additional inbound transactions can be accomodated. restarting(4) : The application is currently unavailable but it is in the process of restarting and will soon be able to process SIP messages. quiescing(5) : The application is currently operational but has been administratively put into quiese mode. Additional inbound transactions may be rejected. testing(6) : The application is currently in test mode and may not be able to process SIP messages. unknown(7) : The operational status cannot be determined for some reason." ::= { sipCommonCfgEntry 2 } --------------------------------------------------------- -- New definition proposal based on sip-mib discussions -- and comments received from Tom Taylor on 10/1/2001 -- sipServiceAdminStatus OBJECT-TYPE SYNTAX INTEGER { noop(1), up(2), down(3), reset(4), quiese_sessions(5), quiese_application(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to affect the overall operational state of the SIP application. When read, this object always return a value of noop(1) since sipServiceOperStatus reflects the actual operational status. noop(1) : Setting this object to a noop value has no effect; when read, this value is always returned. up(2) : Enable the application down(3) : Abrupt shutdown, immediately terminate the application, does not restart. reset(4) : Restart application, reinitialize data. quiese_sessions(5) : Enable quiescence mode. Stop accepting any new SIP sessions. Stop processing new transactions except for transactions associated with an existing session or call. quiese_applications(6):Enable quiescence mode. Stop processing new sip transactions except for transactions associated with existing applications. The exact application behavior should be specified by the implementation." ::= { sipCommonCfgEntry 3 } --------------------------------------- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 15 19:53:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15620 for ; Mon, 15 Oct 2001 19:53:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10141; Mon, 15 Oct 2001 19:26:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10114 for ; Mon, 15 Oct 2001 19:26:33 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15095 for ; Mon, 15 Oct 2001 19:26:32 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA22590 for ; Mon, 15 Oct 2001 18:26:02 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 15 Oct 2001 18:19:05 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Oct 2001 18:25:17 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F21F@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'sip@ietf.org'" Date: Mon, 15 Oct 2001 18:25:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C155D0.A0599AF0" X-Orig: Subject: [Sip] new draft submission for FW/NAT traversal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C155D0.A0599AF0 Content-Type: text/plain; charset="iso-8859-1" Folks, We've submitted an ID called "Midcom-unaware NAT/Firewall Traversal" describing a pre-Midcom solution framework to solve the problem of traversing deployed NAT/FW's. This is in relation to the new extension to the Midcom WG charter calling for "average current practice" solutions for traversing Midcom-unaware, and even, application-unaware NAT/FW's. Two key components of this solution working in tandem are a SIP Proxy & an RTP Proxy. The solution needs interaction between the Proxies, but does not need the clients know about the NAT binds/types and is applicable to all traditional types of NAT's/Firewalls. The draft can be found at: http://www.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt. Comments/feedback are most welcome & should be posted in the Midcom mailing list. Regards, Sanjoy Sen ============ Interactive Multimedia Server, Carrier VoIP Nortel Networks Ph: 972-685-8274, Fax: 972-685-3813 Mobile: 972-571-2062 ------_=_NextPart_001_01C155D0.A0599AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable new draft submission for FW/NAT traversal

Folks,

        We've = submitted an ID called "Midcom-unaware NAT/Firewall = Traversal" describing a pre-Midcom solution framework to solve the = problem of traversing deployed NAT/FW's. This is in relation to the new = extension to the Midcom WG charter calling for "average current = practice" solutions for traversing Midcom-unaware, and even, = application-unaware NAT/FW's. Two key components of this solution = working in tandem are a SIP Proxy & an RTP Proxy. The solution = needs interaction between the Proxies, but does not need the clients = know about the NAT binds/types and is applicable to all traditional = types of NAT's/Firewalls. The draft can be found at: 

http://www.ietf.org/internet-drafts/draft-sen-midcom-f= w-nat-00.txt.

Comments/feedback are most welcome & should be = posted in the Midcom mailing list.

Regards,
Sanjoy Sen

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Interactive Multimedia Server, Carrier VoIP
Nortel Networks
Ph: 972-685-8274, Fax: 972-685-3813
Mobile: 972-571-2062

------_=_NextPart_001_01C155D0.A0599AF0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 15 23:24:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19759 for ; Mon, 15 Oct 2001 23:24:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14794; Mon, 15 Oct 2001 23:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14738 for ; Mon, 15 Oct 2001 23:00:35 -0400 (EDT) Received: from custmail0.corp.aus.wayport.net (custmail0.corp.aus.wayport.net [216.12.231.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19581 for ; Mon, 15 Oct 2001 23:00:34 -0400 (EDT) Received: from eburger (dhcp64-134-115-124.waa.atl.wayport.net [64.134.115.124]) by custmail0.corp.aus.wayport.net (8.11.4/8.11.4) with ESMTP id f9G30Pb29962; Tue, 16 Oct 2001 03:00:25 GMT Reply-To: From: "Eric Burger" To: "Sarvi Shanmugham" , Subject: RE: [Sip] SIP INFO method - Any reason it MUST BE stateless. Date: Mon, 15 Oct 2001 23:02:15 -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) Importance: Normal In-Reply-To: <3BBD0E54.4EE89439@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit My biggest question is, are you thinking of transporting signaling information in the INFO body? If not, why use SIP at all? Are there magic proxies that need to see these messages (i.e., justify on routing)? I would offer that there are other protocols one could use. One choice would be http if your problem is large messages. Another would be to use the NOTIFY message, if what you are trying to accomplish is notification of status changes. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sarvi Shanmugham Sent: Thursday, October 04, 2001 9:35 PM To: sip@ietf.org Subject: [Sip] SIP INFO method - Any reason it MUST BE stateless. Today according to the INFO RFC, the SIP INFO method is stateless, i.e if server A issues an INFO method on an existing SIP session with another server B, and the method body contains some data(lets say a proprietary command, like READFILE abcd.jpg). Server B has to either 1. come back with all the data read in the body of the 200 OK response for the INFO method(it may be large or time consuming) 2. do a 200 OK reponse for the INFO method with an acknowldgement for the READ command and may be an initial chunk. The server B may have to send each subsequent chunk of data on a separate INFO method to A, for which server A has to respond with a 200 OK. This could be highly inefficient. I would have prefered to be able to send one INFO method and get back multiple 18x OK methods carrying the intermediate chunks of data and have the final chunk carry the 200 OK. Is there a specific reason why the the INFO method MUST BE stateless. Because, it looks like the INFO method could be used to get information that may have to come as multiple chunks. thanks, Sarvi _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 02:40:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05150 for ; Tue, 16 Oct 2001 02:40:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25348; Tue, 16 Oct 2001 02:19:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25319 for ; Tue, 16 Oct 2001 02:19:50 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03784 for ; Tue, 16 Oct 2001 02:19:47 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9G6HCC07538; Mon, 15 Oct 2001 23:17:12 -0700 (PDT) Received: from cisco.com (sjc-vpn1-420.cisco.com [10.21.97.164]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAG08223 (AUTH sarvi); Mon, 15 Oct 2001 23:18:54 -0700 (PDT) Message-ID: <3BCBCFDB.B59C44D@cisco.com> Date: Mon, 15 Oct 2001 23:12:44 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: eburger@snowshore.com CC: sip@ietf.org Subject: Re: [Sip] SIP INFO method - Any reason it MUST BE stateless. References: Content-Type: multipart/mixed; boundary="------------A322B9137F8C861FBA2BC0B6" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------A322B9137F8C861FBA2BC0B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Eric, This is not to carry signalling information. The scenario that we are looking at is to setup a SIP session to a media server with a 2-way RTP stream to it. SIP is used for setting up this session. The INFO method would be used to carry commands/information/responses between the applications sitting at either end of the SIP session. Sarvi Eric Burger wrote: > My biggest question is, are you thinking of transporting signaling > information in the INFO body? > > If not, why use SIP at all? Are there magic proxies that need to see these > messages (i.e., justify on routing)? > > I would offer that there are other protocols one could use. One choice > would be http if your problem is large messages. Another would be to use > the NOTIFY message, if what you are trying to accomplish is notification of > status changes. > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sarvi > Shanmugham > Sent: Thursday, October 04, 2001 9:35 PM > To: sip@ietf.org > Subject: [Sip] SIP INFO method - Any reason it MUST BE stateless. > > Today according to the INFO RFC, the SIP INFO method is stateless, > i.e if server A issues an INFO method on an existing SIP session with > another server B, and the method body contains some data(lets say a > proprietary command, like READFILE abcd.jpg). Server B has to either > 1. come back with all the data read in the body of the 200 OK > response for the INFO method(it may be large or time consuming) > 2. do a 200 OK reponse for the INFO method with an acknowldgement > for the READ command and may be an initial chunk. The server B may have > to send each subsequent chunk of data on a separate INFO method to A, > for which server A has to respond with a 200 OK. This could be highly > inefficient. > > I would have prefered to be able to send one INFO method and get back > multiple 18x OK methods carrying the intermediate chunks of data and > have the final chunk carry the 200 OK. > > Is there a specific reason why the the INFO method MUST BE stateless. > > Because, it looks like the INFO method could be used to get information > that may have to come as multiple chunks. > > thanks, > Sarvi --------------A322B9137F8C861FBA2BC0B6 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Saravanan x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Center adr:;;170 W Tasman Drive;San Jose;CA;95134;USA version:2.1 email;internet:sarvi@cisco.com title:Software Engineer fn:Saravanan Shanmugham end:vcard --------------A322B9137F8C861FBA2BC0B6-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 04:52:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07745 for ; Tue, 16 Oct 2001 04:52:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28817; Tue, 16 Oct 2001 04:32:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28785 for ; Tue, 16 Oct 2001 04:32:26 -0400 (EDT) Received: from mail.tduk.com ([195.13.87.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07517 for ; Tue, 16 Oct 2001 04:32:23 -0400 (EDT) Received: from johnslaptop ([195.152.254.142]) by mail.tduk.com (8.11.2/8.11.2) with SMTP id f9G8ekv28300 for ; Tue, 16 Oct 2001 09:40:46 +0100 From: "John Townsend" To: "SIP Mailing List (IETF)" Date: Tue, 16 Oct 2001 09:30:42 +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.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP - INAP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have been trying to find any specs / papers on interworking between INAP (CS1) and SIP. Can anyone help? Regards, John Townsend, Project Manager, Telesoft Technologies Ltd. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 04:56:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07798 for ; Tue, 16 Oct 2001 04:56:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29191; Tue, 16 Oct 2001 04:42:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29160 for ; Tue, 16 Oct 2001 04:42:40 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07641 for ; Tue, 16 Oct 2001 04:42:36 -0400 (EDT) From: abalyan@hss.hns.com Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f9G8hCh12872; Tue, 16 Oct 2001 14:13:13 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256AE7.002FE9A0 ; Tue, 16 Oct 2001 14:13:20 +0530 X-Lotus-FromDomain: HSS To: "John Townsend" cc: "SIP Mailing List (IETF)" Message-ID: <65256AE7.002FE85C.00@sandesh.hss.hns.com> Date: Tue, 16 Oct 2001 14:14:16 +0530 Subject: Re: [Sip] SIP - INAP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi John, It would help if you give some more detail about what exactly you are looking for. SIP is signalling whereas CS1 is a call control model for implementing services You can look at the document Q1218 of ITU-T. Regards Ashish Kumar Balyan Software Engineer Hughes Software Systems "John Townsend" on 10/16/2001 02:00:42 PM To: "SIP Mailing List (IETF)" cc: (bcc: Ashish K Balyan/HSS) Subject: [Sip] SIP - INAP I have been trying to find any specs / papers on interworking between INAP (CS1) and SIP. Can anyone help? Regards, John Townsend, Project Manager, Telesoft Technologies Ltd. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 05:02:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07883 for ; Tue, 16 Oct 2001 05:02:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29037; Tue, 16 Oct 2001 04:38:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29005 for ; Tue, 16 Oct 2001 04:38:45 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07574 for ; Tue, 16 Oct 2001 04:38:42 -0400 (EDT) From: pkkiran@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f9G8dR312663 for ; Tue, 16 Oct 2001 14:09:27 +0530 (IST) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by hsssun01.hss.hns.com (8.8.8+Sun/8.8.8) with SMTP id OAA01266 for ; Tue, 16 Oct 2001 14:17:40 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256AE7.002EE40F ; Tue, 16 Oct 2001 14:02:10 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256AE7.002EE25D.00@sampark.hss.hns.com> Date: Tue, 16 Oct 2001 14:02:22 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Are there any standardized specs for Interworking between SIP and H.323? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Do we have any standards that are already set for the Interworking functionalities between SIP and H.323? If so, please send me the specs document. Thanks and Regards in advance for your concern -Kiran _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 05:03:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07905 for ; Tue, 16 Oct 2001 05:03:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29307; Tue, 16 Oct 2001 04:47:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29278 for ; Tue, 16 Oct 2001 04:47:14 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07688 for ; Tue, 16 Oct 2001 04:47:10 -0400 (EDT) From: seshashayi@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f9G8luC13131; Tue, 16 Oct 2001 14:17:56 +0530 (IST) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by hsssun01.hss.hns.com (8.8.8+Sun/8.8.8) with SMTP id OAA01340; Tue, 16 Oct 2001 14:26:11 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256AE7.002FAE5F ; Tue, 16 Oct 2001 14:10:48 +0530 X-Lotus-FromDomain: HSSBLR To: pkkiran@hss.hns.com cc: sip@ietf.org Message-ID: <65256AE7.002FAE54.00@sampark.hss.hns.com> Date: Tue, 16 Oct 2001 14:11:04 +0530 Subject: Re: [Sip] Are there any standardized specs for Interworking between SIP and H.323? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, There is a draft on SIP-H323 interworking-> draft-singh-sip-h323-01.txt You can follow this link for more info.... http://www.cs.columbia.edu/~kns10/publication/ Rgds Seshu pkkiran@hss.hns.com on 10/16/2001 02:02:22 PM To: sip@ietf.org cc: (bcc: Seshashayi T/HSSBLR) Subject: [Sip] Are there any standardized specs for Interworking between SIP and H.323? Hi Do we have any standards that are already set for the Interworking functionalities between SIP and H.323? If so, please send me the specs document. Thanks and Regards in advance for your concern -Kiran _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 05:28:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08137 for ; Tue, 16 Oct 2001 05:28:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00655; Tue, 16 Oct 2001 05:16:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00623 for ; Tue, 16 Oct 2001 05:16:12 -0400 (EDT) Received: from exchange.isc-software.com (apps.ifs.com [151.204.36.178] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08028 for ; Tue, 16 Oct 2001 05:16:09 -0400 (EDT) Received: from email.masconit.com (MAILHUB [12.41.17.214]) by exchange.isc-software.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJ8Q7GNF; Tue, 16 Oct 2001 05:16:41 -0400 Received: from SREERAM (host130-180.wipro.net.in [202.177.130.180]) by email.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 42TQADRY; Tue, 16 Oct 2001 04:15:32 -0500 Message-ID: <063401c15625$a1f76bd0$8f01c0c0@mas.blr> From: "Sreeram Kanumuri" To: , References: <65256AE7.002EE25D.00@sampark.hss.hns.com> Subject: Re: [Sip] Are there any standardized specs for Interworking between SIP andH.323? Date: Tue, 16 Oct 2001 15:03:20 +0530 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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Kiran, we have "draft-agrawal-sip-h323-interworking" it is still in draft state. you can find it from the itu site. Regards, Sreeram www.masconit.com ----- Original Message ----- From: To: Sent: Tuesday, October 16, 2001 2:02 PM Subject: [Sip] Are there any standardized specs for Interworking between SIP andH.323? > > > Hi > Do we have any standards that are already set for the Interworking > functionalities between SIP and H.323? > If so, please send me the specs document. > Thanks and Regards in advance for your concern > -Kiran > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 05:28:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08149 for ; Tue, 16 Oct 2001 05:28:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00605; Tue, 16 Oct 2001 05:15:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00573 for ; Tue, 16 Oct 2001 05:15:46 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08025 for ; Tue, 16 Oct 2001 05:15:42 -0400 (EDT) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id SAA14270; Tue, 16 Oct 2001 18:15:21 +0900 (JST) (envelope-from makinae.naoto@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp by vcs3.rdh.ecl.ntt.co.jp (8.9.3/3.7W/20010920) with ESMTP id SAA23629; Tue, 16 Oct 2001 18:15:21 +0900 (JST) (envelope-from makinae.naoto@lab.ntt.co.jp) Received: from eclscan3.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id SAA27760; Tue, 16 Oct 2001 18:15:20 +0900 (JST) (envelope-from makinae.naoto@lab.ntt.co.jp) Received: from ima.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA28927; Tue, 16 Oct 2001 18:15:19 +0900 (JST) Received: from Makinae by ima.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id SAA27914; Tue, 16 Oct 2001 18:15:19 +0900 (JST) From: "Naoto MAKINAE" To: "John Townsend" , "SIP Mailing List \(IETF\)" Subject: RE: [Sip] SIP - INAP Date: Tue, 16 Oct 2001 18:15:13 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dear John, Just for your informatin. > I have been trying to find any specs / papers on interworking between INAP > (CS1) and SIP. Can anyone help? The following draft proposes a method for overlaying the IN Call Model over a SIP session/call model, which enables a SIP server to query a Service Control Point for address translation or something. "Accessing IN services from SIP networks" IETF SIN BoF has been working on SIP-IN interworking, but it seems to have been dormant since June. The ML archives are at http://lists.bell-labs.com/mailman/listinfo/ietf-sin naoto -- Naoto MAKINAE Nippon Telegraph & Telephone Co. Email:makinae.naoto@lab.ntt.co.jp _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 05:40:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08270 for ; Tue, 16 Oct 2001 05:40:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00925; Tue, 16 Oct 2001 05:24:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00897 for ; Tue, 16 Oct 2001 05:24:42 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08092 for ; Tue, 16 Oct 2001 05:24:39 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 16 Oct 2001 09:24:43 UT Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 16 Oct 2001 10:25:51 +0100 From: "Neil Deason" To: "John Townsend" , "SIP Mailing List \(IETF\)" Subject: RE: [Sip] SIP - INAP Date: Tue, 16 Oct 2001 10:25:50 +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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 16 Oct 2001 09:25:51.0145 (UTC) FILETIME=[8C0B5990:01C15624] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of John > Townsend > Sent: 16 October 2001 09:31 > To: SIP Mailing List (IETF) > Subject: [Sip] SIP - INAP > > I have been trying to find any specs / papers on interworking > between INAP (CS1) and SIP. Can anyone help? There is a SIP/IN interworking (SIN) design team within the IETF, but there hasn't been much obvious activity there recently: http://lists.bell-labs.com/mailman/listinfo/ietf-sin although one related Internet Draft has come out: http://search.ietf.org/internet-drafts/draft-haerens-sip-in-01.txt Other pieces of work that may be of interest include: SIP implementing IN services http://www.cs.columbia.edu/~hgs/papers/cucs-002-99.pdf IN SCFs using Internet services via SIP http://search.ietf.org/internet-drafts/draft-ietf-spirits-in-01.txt (part of http://search.ietf.org/html.charters/spirits-charter.html) SIP Servers accessing IN services http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip-to-in-05. txt hth, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 06:52:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08735 for ; Tue, 16 Oct 2001 06:52:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02658; Tue, 16 Oct 2001 06:25:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02634 for ; Tue, 16 Oct 2001 06:25:31 -0400 (EDT) Received: from cooper.spectranet.com ([203.122.63.156]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08557 for ; Tue, 16 Oct 2001 06:25:28 -0400 (EDT) Received: from esuims01.esamsungumit.com ([203.122.29.230]) by cooper.spectranet.com (Netscape Messaging Server 4.15) with ESMTP id GLANKO03.20F for ; Tue, 16 Oct 2001 15:54:24 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 16 Oct 2001 15:59:23 +0530 Message-ID: <89CFEE6120A0224EA07781892EC0B48B96F7@esuims01.esamsungumit.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: [Sip] SIP - INAP Thread-Index: AcFWIQ9pIxkxPeZ7TWqKboYNDweBXAAC9UnA From: "ShavinderPal Singh" To: "SIP Mailing List (IETF)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA02635 Subject: [Sip] SIP proxy & redirect server specs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi People, Can anyone help in finding specs/details to design a SIP proxy & redirect server. All I could find is the RFC 2543. which does not tell much. Please tell me all the stuff which can help me design a server. Thnx & rgds, -s eSamsung UI, 15th floor, Signature Towers, South City-I, Gurgaon-122001, HR, IND. Ph.: 091-124-6383474 (e 226) __________________________________________ I had a good grip on life, but then the handle broke. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 07:27:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09632 for ; Tue, 16 Oct 2001 07:27:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03913; Tue, 16 Oct 2001 07:06:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03879 for ; Tue, 16 Oct 2001 07:06:34 -0400 (EDT) Received: from stewart.spectranet.com ([203.122.63.155]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08871 for ; Tue, 16 Oct 2001 07:06:31 -0400 (EDT) Received: from esuims01.esamsungumit.com ([203.122.29.230]) by stewart.spectranet.com (Netscape Messaging Server 4.15) with ESMTP id GLAPE003.H02; Tue, 16 Oct 2001 16:33:36 +0530 Subject: RE: [Sip] SIP proxy & redirect server specs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 16 Oct 2001 16:37:26 +0530 Message-ID: <89CFEE6120A0224EA07781892EC0B48B970F@esuims01.esamsungumit.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: [Sip] SIP proxy & redirect server specs Thread-Index: AcFWMb6wrKAeKRBNRbW2HUFbdhKvwgAAGbSQ From: "ShavinderPal Singh" To: "Sreeram Kanumuri" , "SIP Mailing List (IETF)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA03880 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit i do have a lot of specs on SIP as such. and yes i did go thru the columbia univ. site already. BUT what i need is a guidline to desing a proxy server and a redirect server. Something like a recomnedation kind of thing. Or a design documnet for a proxy/redirect server ,reading which i can get the whole underlying desing principle. something more to the RFC 2543, but more only specifically for 'proxy & redirect'. my fundas on the SIP protocol are clear, but i need it on the server thing now! rgds, -s __________________________________________ I had a good grip on life, but then the handle broke. -----Original Message----- From: Sreeram Kanumuri [mailto:skanumuri@email.masconit.com] Sent: Tuesday, October 16, 2001 4:43 PM To: ShavinderPal Singh; SIP Mailing List (IETF) Subject: Re: [Sip] SIP proxy & redirect server specs Hi, go threw www.cs.columbia.edu/sip there u can find more details about SIP . -sreeram ----- Original Message ----- From: "ShavinderPal Singh" To: "SIP Mailing List (IETF)" Sent: Tuesday, October 16, 2001 3:59 PM Subject: [Sip] SIP proxy & redirect server specs > Hi People, > Can anyone help in finding specs/details to design a SIP proxy & > redirect server. > All I could find is the RFC 2543. which does not tell much. > > Please tell me all the stuff which can help me design a server. > > > Thnx & rgds, > -s > > eSamsung UI, 15th floor, Signature Towers, > South City-I, Gurgaon-122001, HR, IND. > Ph.: 091-124-6383474 (e 226) > __________________________________________ > I had a good grip on life, but then the handle broke. > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 07:34:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09803 for ; Tue, 16 Oct 2001 07:34:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03379; Tue, 16 Oct 2001 06:56:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03350 for ; Tue, 16 Oct 2001 06:56:05 -0400 (EDT) Received: from exchange.isc-software.com (apps.ifs.com [151.204.36.178] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08758 for ; Tue, 16 Oct 2001 06:56:04 -0400 (EDT) Received: from email.masconit.com (MAILHUB [12.41.17.214]) by exchange.isc-software.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJ8Q7GRV; Tue, 16 Oct 2001 06:56:35 -0400 Received: from SREERAM (host130-180.wipro.net.in [202.177.130.180]) by email.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 42TQAD5G; Tue, 16 Oct 2001 05:55:29 -0500 Message-ID: <06e901c15633$93c756c0$8f01c0c0@mas.blr> From: "Sreeram Kanumuri" To: "ShavinderPal Singh" , "SIP Mailing List \(IETF\)" References: <89CFEE6120A0224EA07781892EC0B48B96F7@esuims01.esamsungumit.com> Subject: Re: [Sip] SIP proxy & redirect server specs Date: Tue, 16 Oct 2001 16:43:16 +0530 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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, go threw www.cs.columbia.edu/sip there u can find more details about SIP . -sreeram ----- Original Message ----- From: "ShavinderPal Singh" To: "SIP Mailing List (IETF)" Sent: Tuesday, October 16, 2001 3:59 PM Subject: [Sip] SIP proxy & redirect server specs > Hi People, > Can anyone help in finding specs/details to design a SIP proxy & > redirect server. > All I could find is the RFC 2543. which does not tell much. > > Please tell me all the stuff which can help me design a server. > > > Thnx & rgds, > -s > > eSamsung UI, 15th floor, Signature Towers, > South City-I, Gurgaon-122001, HR, IND. > Ph.: 091-124-6383474 (e 226) > __________________________________________ > I had a good grip on life, but then the handle broke. > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 15:01:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15657 for ; Tue, 16 Oct 2001 15:01:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17258; Tue, 16 Oct 2001 14:18:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17227 for ; Tue, 16 Oct 2001 14:18:17 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13802 for ; Tue, 16 Oct 2001 14:18:15 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9GIHl005904 for ; Tue, 16 Oct 2001 13:17:47 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9GIHk109878 for ; Tue, 16 Oct 2001 13:17:47 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Oct 16 13:17:46 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP0AG78>; Tue, 16 Oct 2001 13:17:46 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'sip@ietf.org'" Date: Tue, 16 Oct 2001 13:17:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1566E.DABD87D0" Subject: [Sip] Call-Info: header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1566E.DABD87D0 Content-Type: text/plain; charset="iso-8859-1" Hi, I'm sure this has been discussed before. I don't want to re-open a discussion if a conclusion has been made. In draft-lennox-sip-reg-payload-01.txt, it was proposed to extend the list of disposition-types for the Content-Disposition: header to include "script". I would like to make a similar proposal to extend the list of "purpose" tokens for Call-Info: to include script. The Call-Info: header could then contain a URL to something like a vxml script which could be optionally processed by the receiving party. Because the current syntax allows a token for this parameter, there isn't technically a need to standardize this, but I was wondering if there were strong opinions either way about including this in the bis draft? Regards, Sean Olson Ericsson Inc. ------_=_NextPart_001_01C1566E.DABD87D0 Content-Type: text/html; charset="iso-8859-1" Call-Info: header

Hi,

I'm sure this has been discussed before. I don't
want to re-open a discussion if a conclusion has
been made. In draft-lennox-sip-reg-payload-01.txt,
it was proposed to extend the list of disposition-types for
the Content-Disposition: header to include "script".
I would like to make a similar proposal to extend
the list of "purpose" tokens for Call-Info: to include
script. The Call-Info: header could then contain a
URL to something like a vxml script which could be
optionally processed by the receiving party.

Because the current syntax allows a token for this
parameter, there isn't technically a need to standardize
this, but I was wondering if there were strong opinions
either way about including this in the bis draft?

Regards,
Sean Olson
Ericsson Inc.

------_=_NextPart_001_01C1566E.DABD87D0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 15:08:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15970 for ; Tue, 16 Oct 2001 15:08:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18221; Tue, 16 Oct 2001 14:45:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18193 for ; Tue, 16 Oct 2001 14:45:46 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14996 for ; Tue, 16 Oct 2001 14:45:44 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9GIBSY21983 for ; Tue, 16 Oct 2001 13:11:28 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9GIBSG25074 for ; Tue, 16 Oct 2001 13:11:28 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Oct 16 13:11:00 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP0AGMA>; Tue, 16 Oct 2001 13:11:00 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'sip@ietf.org'" Date: Tue, 16 Oct 2001 13:10:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1566D.E7D7AD20" Subject: [Sip] Alert-Info: header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1566D.E7D7AD20 Content-Type: text/plain; charset="iso-8859-1" Hi, I was wondering if it would be possible to make Alert-Info: a general header instead of a request header. In particular, it would be nice to be able to use the Alert-Info: header to carry an appropriate URL in a 180 Ringing response. The change I am proposing is: The Alert-Info header field indicates that the content indicated in the URLs should be rendered instead of ring tone or ringback tone. A user SHOULD be able to disable this feature selectively to prevent unauthorized disruptions. When present in a request, the Alert-Info header specifies an alternative ring tone. When present in a response, the Alert-Info header specifies an alternative ringback tone. Alert-Info = "Alert-Info" ":" # ( "<" URI ">" *( ";" generic-param )) generic-param = token [ "=" ( token | host | quoted-string ) ] Example: Alert-Info: Comments? Sean Olson Ericsson Inc. ------_=_NextPart_001_01C1566D.E7D7AD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alert-Info: header

Hi,

I was wondering if it would be possible to make =
Alert-Info: a general header instead of a = request
header. In particular, it would be nice to be
able to use the Alert-Info: header to carry = an
appropriate URL in a 180 Ringing response.
The change I am proposing is:

   The Alert-Info header field indicates = that the content indicated in
   the URLs should be rendered instead of = ring tone or ringback tone.
   A user SHOULD be able to disable this = feature selectively to prevent
   unauthorized disruptions. When present = in a request, the Alert-Info
   header specifies an alternative ring = tone. When present in a response,
   the Alert-Info header specifies an = alternative ringback tone.

        = Alert-Info     =3D  "Alert-Info" = ":" # ( "<" URI ">" *( = ";" generic-param ))
        = generic-param  =3D  token [ "=3D" ( token | host | = quoted-string ) ]

   Example:
   Alert-Info: <http://wwww.example.com/sounds/moo.wav>


Comments?
Sean Olson
Ericsson Inc.

------_=_NextPart_001_01C1566D.E7D7AD20-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 15:27:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16859 for ; Tue, 16 Oct 2001 15:27:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19027; Tue, 16 Oct 2001 15:02:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18998 for ; Tue, 16 Oct 2001 15:02:45 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15710 for ; Tue, 16 Oct 2001 15:02:45 -0400 (EDT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GLB004FLBINYZ@firewall.wcom.com> for sip@ietf.org; Tue, 16 Oct 2001 19:01:36 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GLB00901BHSDV@dgismtp03.wcomnet.com>; Tue, 16 Oct 2001 19:01:35 +0000 (GMT) Received: from wcom.com ([166.42.32.213]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GLB008ARBHDGQ@dgismtp03.wcomnet.com>; Tue, 16 Oct 2001 19:00:50 +0000 (GMT) Date: Tue, 16 Oct 2001 14:01:50 -0500 From: Alan Johnston Subject: Re: [Sip] Alert-Info: header To: "Sean Olson (EUS)" Cc: "'sip@ietf.org'" Message-id: <3BCC841D.114FB009@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean, I have always assumed that the Alert-Info header being listed as a Request header was an error - it only makes sense for it to be used as you describe - in a response (180 Ringing, to be specific, since this is the only SIP response that tells the UAC to play ringback tone to the caller). This then allows a UAS to deliver a customizable ringback tone without resorting to early media. The use of Alert-Info in an INVITE never made any sense to me. There would be a delay in the UAS from the receipt of the INVITE until it had fetched the alert sound. Then, assuming that the UAS played the sound, how would the user even know that his SIP phone or client was ringing? Used the other way around, the header does not introduce a delay in the session setup (a delay of audible ringback while the UAC fetches the ringback sound does not delay the UAS answering), and the caller just hears a different sound besides ringing, something perfectly possible with early media, but handled in a much more efficient way using this header. This is how this header will be described in bis-05, so let me know if I am totally off base here. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com "Sean Olson (EUS)" wrote: > > > Hi, > > I was wondering if it would be possible to make > Alert-Info: a general header instead of a request > header. In particular, it would be nice to be > able to use the Alert-Info: header to carry an > appropriate URL in a 180 Ringing response. > The change I am proposing is: > > The Alert-Info header field indicates that the content indicated in > > the URLs should be rendered instead of ring tone or ringback tone. > A user SHOULD be able to disable this feature selectively to > prevent > unauthorized disruptions. When present in a request, the Alert-Info > > header specifies an alternative ring tone. When present in a > response, > the Alert-Info header specifies an alternative ringback tone. > > Alert-Info = "Alert-Info" ":" # ( "<" URI ">" *( ";" > generic-param )) > generic-param = token [ "=" ( token | host | quoted-string ) > ] > > Example: > Alert-Info: > > Comments? > Sean Olson > Ericsson Inc. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 15:47:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17834 for ; Tue, 16 Oct 2001 15:47:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19835; Tue, 16 Oct 2001 15:24:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19804 for ; Tue, 16 Oct 2001 15:24:14 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16780 for ; Tue, 16 Oct 2001 15:24:13 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9GJNk018215 for ; Tue, 16 Oct 2001 14:23:46 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9GJNk111534 for ; Tue, 16 Oct 2001 14:23:46 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Oct 16 14:23:45 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP0AM1L>; Tue, 16 Oct 2001 14:23:45 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Alan Johnston'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Alert-Info: header Date: Tue, 16 Oct 2001 14:23:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15678.117466F0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C15678.117466F0 Content-Type: text/plain; charset="iso-8859-1" >Sean, > >I have always assumed that the Alert-Info header being listed as a >Request header was an error - it only makes sense for it to be used as >you describe - in a response (180 Ringing, to be specific, >since this is >the only SIP response that tells the UAC to play ringback tone to the >caller). > >This then allows a UAS to deliver a customizable ringback tone without >resorting to early media. Yes, this is the primary feature I am looking for. However, it is not the only feature I would like to support with this header. For this reason, I think Alert-Info should remain a general header. I will elaborate further below. > >The use of Alert-Info in an INVITE never made any sense to me. There >would be a delay in the UAS from the receipt of the INVITE until it had >fetched the alert sound. Then, assuming that the UAS played the sound, >how would the user even know that his SIP phone or client was ringing? This is fairly confusing if you assume that the Alert-Info: can only apply to ring(back) tone. If you broaden the header to mean "this is information to be rendered to the end user during the alerting period", then things start to make more sense. For example, if I send an http: URL in the Alert-Info: header in the INVITE, this could point to a thumbnail icon which provides an enhanced caller ID feature. Or an http: URL could point to .wav file that could be interpreted as an alternative to ring tone. Naturally for a SIP device to make this meaningful to the end user, it has to be intelligent about how it renders this media and flexible in its notion of "ringing". I would expect that a device that supported this feature would first "alert" the user using a default ring tone coupled with an appropriate message on a LCD display. When the resource identified by the Alert-Info: header is retrieved, the device should use the MIME type and some reasonable heuristics to determine how to render and/or mix the media with the default "ring tone" at the device. > >Used the other way around, the header does not introduce a delay in the >session setup (a delay of audible ringback while the UAC fetches the >ringback sound does not delay the UAS answering), and the caller just >hears a different sound besides ringing, something perfectly possible >with early media, but handled in a much more efficient way using this >header. Yes, this direction is more inline with what we have today. I would still like to support the reverse direction as well. Leave it to the device to figure out what it wants to do. I'm certain there will be service features in the future which will want to use Alert-Info in both directions. > >This is how this header will be described in bis-05, so let me >know if I >am totally off base here. > >Thanks, >Alan Johnston >WorldCom >sip:alan@siptest.wcom.com Thanks for the quick response. I hope my comments make sense. Sean > >"Sean Olson (EUS)" wrote: > >> >> >> Hi, >> >> I was wondering if it would be possible to make >> Alert-Info: a general header instead of a request >> header. In particular, it would be nice to be >> able to use the Alert-Info: header to carry an >> appropriate URL in a 180 Ringing response. >> The change I am proposing is: >> >> The Alert-Info header field indicates that the content >indicated in >> >> the URLs should be rendered instead of ring tone or ringback tone. >> A user SHOULD be able to disable this feature selectively to >> prevent >> unauthorized disruptions. When present in a request, the >Alert-Info >> >> header specifies an alternative ring tone. When present in a >> response, >> the Alert-Info header specifies an alternative ringback tone. >> >> Alert-Info = "Alert-Info" ":" # ( "<" URI ">" *( ";" >> generic-param )) >> generic-param = token [ "=" ( token | host | >quoted-string ) >> ] >> >> Example: >> Alert-Info: >> >> Comments? >> Sean Olson >> Ericsson Inc. > ------_=_NextPart_001_01C15678.117466F0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Alert-Info: header

>Sean,
>
>I have always assumed that the Alert-Info header being listed as a
>Request header was an error - it only makes sense for it to be used as
>you describe - in a response (180 Ringing, to be specific,
>since this is
>the only SIP response that tells the UAC to play ringback tone to the
>caller).
>
>This then allows a UAS to deliver a customizable ringback tone without
>resorting to early media.

Yes, this is the primary feature I am looking for. However, it is
not the only feature I would like to support with this header.
For this reason, I think Alert-Info should remain a general header.
I will elaborate further below.

>
>The use of Alert-Info in an INVITE never made any sense to me.  There
>would be a delay in the UAS from the receipt of the INVITE until it had
>fetched the alert sound.  Then, assuming that the UAS played the sound,
>how would the user even know that his SIP phone or client was ringing?

This is fairly confusing if you assume that the Alert-Info: can
only apply to ring(back) tone. If you broaden the header to mean
"this is information to be rendered to the end user during the
alerting period", then things start to make more sense. For example,
if I send an http: URL in the Alert-Info: header in the INVITE, this
could point to a thumbnail icon which provides an enhanced caller ID
feature. Or an http: URL could point to .wav file that could be
interpreted as an alternative to ring tone. Naturally for a SIP device
to make this meaningful to the end user, it has to be intelligent about
how it renders this media and flexible in its notion of "ringing". I would
expect that a device that supported this feature would first "alert" the
user using a default ring tone coupled with an appropriate message on a
LCD display. When the resource identified by the Alert-Info: header is
retrieved, the device should use the MIME type and some reasonable heuristics
to determine how to render and/or mix the media with the default "ring tone"
at the device.

>
>Used the other way around, the header does not introduce a delay in the
>session setup (a delay of audible ringback while the UAC fetches the
>ringback sound does not delay the UAS answering), and the caller just
>hears a different sound besides ringing, something perfectly possible
>with early media, but handled in a much more efficient way using this
>header.

Yes, this direction is more inline with what we have today. I would
still like to support the reverse direction as well. Leave it to the
device to figure out what it wants to do.  I'm certain there will
be service features in the future which will want to use Alert-Info
in both directions.

>
>This is how this header will be described in bis-05, so let me
>know if I
>am totally off base here.
>
>Thanks,
>Alan Johnston
>WorldCom
>sip:alan@siptest.wcom.com

Thanks for the quick response. I hope my comments make sense.
Sean

>
>"Sean Olson (EUS)" wrote:
>
>>
>>
>> Hi,
>>
>> I was wondering if it would be possible to make
>> Alert-Info: a general header instead of a request
>> header. In particular, it would be nice to be
>> able to use the Alert-Info: header to carry an
>> appropriate URL in a 180 Ringing response.
>> The change I am proposing is:
>>
>>    The Alert-Info header field indicates that the content
>indicated in
>>
>>    the URLs should be rendered instead of ring tone or ringback tone.
>>    A user SHOULD be able to disable this feature selectively to
>> prevent
>>    unauthorized disruptions. When present in a request, the
>Alert-Info
>>
>>    header specifies an alternative ring tone. When present in a
>> response,
>>    the Alert-Info header specifies an alternative ringback tone.
>>
>>         Alert-Info     =  "Alert-Info" ":" # ( "<" URI ">" *( ";"
>> generic-param ))
>>         generic-param  =  token [ "=" ( token | host |
>quoted-string )
>> ]
>>
>>    Example:
>>    Alert-Info: <http://wwww.example.com/sounds/moo.wav>
>>
>> Comments?
>> Sean Olson
>> Ericsson Inc.
>

------_=_NextPart_001_01C15678.117466F0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 16:13:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19267 for ; Tue, 16 Oct 2001 16:13:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20722; Tue, 16 Oct 2001 15:44:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20692 for ; Tue, 16 Oct 2001 15:44:01 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17706 for ; Tue, 16 Oct 2001 15:44:00 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f9GJhwZ79430; Tue, 16 Oct 2001 15:43:58 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Alan Johnston'" , "'Sean Olson \(EUS\)'" Cc: Subject: RE: [Sip] Alert-Info: header Date: Tue, 16 Oct 2001 15:44:25 -0400 Message-ID: <003201c1567a$f69f7a10$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3BCC841D.114FB009@wcom.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The use of Alert-Info in an INVITE never made any sense to me. There > would be a delay in the UAS from the receipt of the INVITE > until it had > fetched the alert sound. Then, assuming that the UAS played > the sound, > how would the user even know that his SIP phone or client was ringing? > > Used the other way around, the header does not introduce a > delay in the > session setup (a delay of audible ringback while the UAC fetches the > ringback sound does not delay the UAS answering), and the caller just > hears a different sound besides ringing, something perfectly possible > with early media, but handled in a much more efficient way using this > header. > > This is how this header will be described in bis-05, so let > me know if I > am totally off base here. It needs to remain an option for INVITE's so that a proxy can indicate distinctive/priority alerting to its user. I am fine with its usage in other requests and response. It could help a UAS to indicate that it can no longer apply remote ringback; thus please apply it locally. However if the header is present anywhere except the first INVITE, parameters or documented text would need to describe its relationship to current media streams. For instance, listen/render until media received. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 16:31:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19984 for ; Tue, 16 Oct 2001 16:31:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21847; Tue, 16 Oct 2001 16:05:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21815 for ; Tue, 16 Oct 2001 16:05:41 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19096 for ; Tue, 16 Oct 2001 16:05:39 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA16920; Tue, 16 Oct 2001 16:05:30 -0400 (EDT) Message-ID: <3BCC930A.F417D203@cs.columbia.edu> Date: Tue, 16 Oct 2001 16:05:30 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Johnston CC: "Sean Olson (EUS)" , "'sip@ietf.org'" Subject: Re: [Sip] Alert-Info: header References: <3BCC841D.114FB009@wcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Alan Johnston wrote: > > Sean, > > I have always assumed that the Alert-Info header being listed as a > Request header was an error - it only makes sense for it to be used as > you describe - in a response (180 Ringing, to be specific, since this is > the only SIP response that tells the UAC to play ringback tone to the > caller). > > This then allows a UAS to deliver a customizable ringback tone without > resorting to early media. This is for *ring* tone, not *ringback* tone. > > The use of Alert-Info in an INVITE never made any sense to me. There > would be a delay in the UAS from the receipt of the INVITE until it had > fetched the alert sound. Then, assuming that the UAS played the sound, > how would the user even know that his SIP phone or client was ringing? > The delay would often be minuscule (a second or less), in particular if the Alert-Info is inserted by the local proxy on the receiving side (e.g., to do caller-dependent ring tones). I don't understand the last question. If the URL is sound, the callee would hear it... > Used the other way around, the header does not introduce a delay in the > session setup (a delay of audible ringback while the UAC fetches the > ringback sound does not delay the UAS answering), and the caller just > hears a different sound besides ringing, something perfectly possible > with early media, but handled in a much more efficient way using this > header. > > This is how this header will be described in bis-05, so let me know if I > am totally off base here. Yes, unfortunately. > > Thanks, > Alan Johnston > WorldCom > sip:alan@siptest.wcom.com > > "Sean Olson (EUS)" wrote: > p -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 16:52:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20667 for ; Tue, 16 Oct 2001 16:52:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22222; Tue, 16 Oct 2001 16:23:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22191 for ; Tue, 16 Oct 2001 16:23:13 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19647 for ; Tue, 16 Oct 2001 16:23:11 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f9GKND688338; Tue, 16 Oct 2001 16:23:13 -0400 (EDT) Reply-To: From: "Brett Tate" To: Cc: Date: Tue, 16 Oct 2001 16:23:41 -0400 Message-ID: <003601c15680$72ce4d50$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-refer-01 comment Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit draft-ietf-sip-refer-01 defines Refer-To = ("Refer-To" | "r") ":" URL Then it includes example Refer-To: The example should not have the URL incapsulated in the <>. If I am incorrect, please let me know. Thanks. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 18:35:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22260 for ; Tue, 16 Oct 2001 18:35:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25405; Tue, 16 Oct 2001 18:16:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25374 for ; Tue, 16 Oct 2001 18:16:52 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21953 for ; Tue, 16 Oct 2001 18:16:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9GMF68P015829; Tue, 16 Oct 2001 18:15:08 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQJNG>; Tue, 16 Oct 2001 18:16:15 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E6BC@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'brett@broadsoft.com'" Cc: sip@ietf.org Date: Tue, 16 Oct 2001 18:16:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: draft-ietf-sip-refer-01 comment Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org You are correct. RjS > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Tuesday, October 16, 2001 3:24 PM > To: rsparks@dynamicsoft.com > Cc: sip@ietf.org > Subject: draft-ietf-sip-refer-01 comment > > > draft-ietf-sip-refer-01 defines > Refer-To = ("Refer-To" | "r") ":" URL > > Then it includes example > > Refer-To: Replaces:12345%40192.168.118.3; > to-tag=12345;from-tag=5FFE-3994> > > The example should not have the > URL incapsulated in the <>. > If I am incorrect, please let me know. > > Thanks. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 19:05:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22641 for ; Tue, 16 Oct 2001 19:05:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26413; Tue, 16 Oct 2001 18:50:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26318 for ; Tue, 16 Oct 2001 18:50:30 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22444 for ; Tue, 16 Oct 2001 18:50:27 -0400 (EDT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GLB00DGVM3C4L@firewall.wcom.com> for sip@ietf.org; Tue, 16 Oct 2001 22:50:01 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GLB00301M37KQ@pmismtp03.wcomnet.com>; Tue, 16 Oct 2001 22:50:00 +0000 (GMT) Received: from wcom.com ([166.42.32.53]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GLB0026ZM2X6V@pmismtp03.wcomnet.com>; Tue, 16 Oct 2001 22:49:47 +0000 (GMT) Date: Tue, 16 Oct 2001 17:50:45 -0500 From: Alan Johnston Subject: Re: [Sip] Alert-Info: header To: "Henning G. Schulzrinne" Cc: "Sean Olson (EUS)" , "'sip@ietf.org'" Message-id: <3BCCB9C5.E9321C0@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3BCC841D.114FB009@wcom.com> <3BCC930A.F417D203@cs.columbia.edu> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning, So are you opposed to the use of this header as Sean describes it? The use of the header for personalized ringback without resorting to early media is a good idea. As for its use in distinctive ringing, we'll just need a note to say that the use of this header requires the strongest security and trust relationship otherwise it will be the cause of the worst kind of SPAM. Thanks, Alan. "Henning G. Schulzrinne" wrote: > Alan Johnston wrote: > > > > Sean, > > > > I have always assumed that the Alert-Info header being listed as a > > Request header was an error - it only makes sense for it to be used as > > you describe - in a response (180 Ringing, to be specific, since this is > > the only SIP response that tells the UAC to play ringback tone to the > > caller). > > > > This then allows a UAS to deliver a customizable ringback tone without > > resorting to early media. > > This is for *ring* tone, not *ringback* tone. > > > > > The use of Alert-Info in an INVITE never made any sense to me. There > > would be a delay in the UAS from the receipt of the INVITE until it had > > fetched the alert sound. Then, assuming that the UAS played the sound, > > how would the user even know that his SIP phone or client was ringing? > > > > The delay would often be minuscule (a second or less), in particular if > the Alert-Info is inserted by the local proxy on the receiving side > (e.g., to do caller-dependent ring tones). > > I don't understand the last question. If the URL is sound, the callee > would hear it... > > > Used the other way around, the header does not introduce a delay in the > > session setup (a delay of audible ringback while the UAC fetches the > > ringback sound does not delay the UAS answering), and the caller just > > hears a different sound besides ringing, something perfectly possible > > with early media, but handled in a much more efficient way using this > > header. > > > > This is how this header will be described in bis-05, so let me know if I > > am totally off base here. > > Yes, unfortunately. > > > > > Thanks, > > Alan Johnston > > WorldCom > > sip:alan@siptest.wcom.com > > > > "Sean Olson (EUS)" wrote: > > > p > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 19:08:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22668 for ; Tue, 16 Oct 2001 19:08:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26503; Tue, 16 Oct 2001 18:55:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26472 for ; Tue, 16 Oct 2001 18:55:34 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22544 for ; Tue, 16 Oct 2001 18:55:29 -0400 (EDT) Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Oct 2001 15:54:08 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 15:54:06 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 15:54:06 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Tue, 16 Oct 2001 15:53:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 16 Oct 2001 15:53:36 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC121BA0A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: 407s from different proxies on a SIP session Thread-Index: AcFWlXTZG/JVAJO8Sc2Kf+4OUMD7rg== From: "Ajay Chitturi" To: X-OriginalArrivalTime: 16 Oct 2001 22:53:36.0783 (UTC) FILETIME=[63D0D1F0:01C15695] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA26473 Subject: [Sip] 407s from different proxies on a SIP session Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, In the following scenario with multiple proxies, each of the proxies can challenge the request from the client and the client will probably have to respond to the challenges from different proxies using different Proxy-Authorization headers in the same request. How do the proxies differentiate between the different Proxy-Authorization headers and use the right header that was meant for the proxy. I was wondering if there was a standard way to do this. C1 ---------> P1 ------------> P2 ---------------> C2 Thanks Ajay. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 20:27:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23193 for ; Tue, 16 Oct 2001 20:27:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26974; Tue, 16 Oct 2001 19:08:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26942 for ; Tue, 16 Oct 2001 19:08:30 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22680 for ; Tue, 16 Oct 2001 19:08:29 -0400 (EDT) From: John.Hearty@level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id XAA06293; Tue, 16 Oct 2001 23:08:30 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id XAA15740; Tue, 16 Oct 2001 23:08:30 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <4GXQ452K>; Tue, 16 Oct 2001 17:08:29 -0600 Message-ID: <17052388D394D411803900508BDFFAF601B36F7F@n0214idc1.oss.level3.com> To: alan.johnston@wcom.com, hgs@cs.columbia.edu Cc: sean.olson@ericsson.com, sip@ietf.org Subject: RE: [Sip] Alert-Info: header Date: Tue, 16 Oct 2001 17:08:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think using the header for both purposes is overloading it. The idea is good, but a different header should be used. Good point on the spam! That might wind up killing the intended functionality from getting implemented. John Hearty Level3 -----Original Message----- From: Alan Johnston [mailto:alan.johnston@wcom.com] Sent: Tuesday, October 16, 2001 4:51 PM To: Henning G. Schulzrinne Cc: Sean Olson (EUS); 'sip@ietf.org' Subject: Re: [Sip] Alert-Info: header Henning, So are you opposed to the use of this header as Sean describes it? The use of the header for personalized ringback without resorting to early media is a good idea. As for its use in distinctive ringing, we'll just need a note to say that the use of this header requires the strongest security and trust relationship otherwise it will be the cause of the worst kind of SPAM. Thanks, Alan. "Henning G. Schulzrinne" wrote: > Alan Johnston wrote: > > > > Sean, > > > > I have always assumed that the Alert-Info header being listed as a > > Request header was an error - it only makes sense for it to be used as > > you describe - in a response (180 Ringing, to be specific, since this is > > the only SIP response that tells the UAC to play ringback tone to the > > caller). > > > > This then allows a UAS to deliver a customizable ringback tone without > > resorting to early media. > > This is for *ring* tone, not *ringback* tone. > > > > > The use of Alert-Info in an INVITE never made any sense to me. There > > would be a delay in the UAS from the receipt of the INVITE until it had > > fetched the alert sound. Then, assuming that the UAS played the sound, > > how would the user even know that his SIP phone or client was ringing? > > > > The delay would often be minuscule (a second or less), in particular if > the Alert-Info is inserted by the local proxy on the receiving side > (e.g., to do caller-dependent ring tones). > > I don't understand the last question. If the URL is sound, the callee > would hear it... > > > Used the other way around, the header does not introduce a delay in the > > session setup (a delay of audible ringback while the UAC fetches the > > ringback sound does not delay the UAS answering), and the caller just > > hears a different sound besides ringing, something perfectly possible > > with early media, but handled in a much more efficient way using this > > header. > > > > This is how this header will be described in bis-05, so let me know if I > > am totally off base here. > > Yes, unfortunately. > > > > > Thanks, > > Alan Johnston > > WorldCom > > sip:alan@siptest.wcom.com > > > > "Sean Olson (EUS)" wrote: > > > p > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 21:23:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23665 for ; Tue, 16 Oct 2001 21:23:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29016; Tue, 16 Oct 2001 20:50:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28982 for ; Tue, 16 Oct 2001 20:50:36 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23364 for ; Tue, 16 Oct 2001 20:50:34 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f9H0oZ340421; Tue, 16 Oct 2001 20:50:35 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Ajay Chitturi'" Cc: Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Tue, 16 Oct 2001 20:51:03 -0400 Message-ID: <003901c156a5$ccd99a50$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC121BA0A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > In the following scenario with multiple proxies, each of the > proxies can challenge the request from the client and the > client will probably have to respond to the challenges from > different proxies using different Proxy-Authorization headers > in the same request. How do the proxies differentiate between > the different Proxy-Authorization headers and use the right > header that was meant for the proxy. I was wondering if there > was a standard way to do this. > > C1 ---------> P1 ------------> P2 ---------------> C2 > The realm can be used if the proxy is certain that it is unique to the proxy. Otherwise, the nonce can be generated/parsed in a way that uniquely identifies the appropriate proxy. RFC 2617 defines additional parameters that could be used assuming that the client isn't limited to RFC 2069. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 23:17:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26810 for ; Tue, 16 Oct 2001 23:17:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01936; Tue, 16 Oct 2001 22:54:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01907 for ; Tue, 16 Oct 2001 22:54:49 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26590 for ; Tue, 16 Oct 2001 22:54:48 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA03252; Tue, 16 Oct 2001 22:54:46 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id WAA02621; Tue, 16 Oct 2001 22:54:40 -0400 (EDT) Message-ID: <3BCCF348.9277649E@cs.columbia.edu> Date: Tue, 16 Oct 2001 22:56:08 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John.Hearty@level3.com CC: alan.johnston@wcom.com, sean.olson@ericsson.com, sip@ietf.org Subject: Re: [Sip] Alert-Info: header References: <17052388D394D411803900508BDFFAF601B36F7F@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It seems to be unambiguous with a single name; one advantage is that it generally seems to help to define the behavior of headers in both directions. See earlier message about spam. In some cases, even if you allow random URLs, this can actually help. If I hear the local [your least favorite telephone company here] jingle, I will press the deep-six (603) button without bothering to lift the receiver. It is somewhat unfortunate that existing SIP phones don't have this button... John.Hearty@Level3.com wrote: > > I think using the header for both purposes is overloading it. The idea is > good, but a different header should be used. Good point on the spam! That > might wind up killing the intended functionality from getting implemented. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 16 23:17:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26845 for ; Tue, 16 Oct 2001 23:17:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01827; Tue, 16 Oct 2001 22:50:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01798 for ; Tue, 16 Oct 2001 22:49:59 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26523 for ; Tue, 16 Oct 2001 22:49:58 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA02974; Tue, 16 Oct 2001 22:50:01 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id WAA02606; Tue, 16 Oct 2001 22:50:00 -0400 (EDT) Message-ID: <3BCCF230.949B52B3@cs.columbia.edu> Date: Tue, 16 Oct 2001 22:51:28 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alan Johnston CC: "Sean Olson (EUS)" , "'sip@ietf.org'" Subject: Re: [Sip] Alert-Info: header References: <3BCC841D.114FB009@wcom.com> <3BCC930A.F417D203@cs.columbia.edu> <3BCCB9C5.E9321C0@wcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Alan Johnston wrote: > > Henning, > > So are you opposed to the use of this header as Sean describes it? The use > of the header for personalized ringback without resorting to early media is a > good idea. No, I'm not opposed to this - sorry if my message came across as such. It's indeed a very useful feature (I vaguely remember that this was discussed when this topic came up the first time around). > > As for its use in distinctive ringing, we'll just need a note to say that the > use of this header requires the strongest security and trust relationship > otherwise it will be the cause of the worst kind of SPAM. Yes, although the potential for mischief seems to exist in both directions, to different degrees. One potential easy check is for the user to only allow local ring tone URLs (or URLs from the provider's domain); this prevents the spam case you mention, but still provides the distinctive ringing service. Indeed, if the URL path name is a random string, it's pretty difficult for an outsider to guess and invoke without the callee's consent. Not sure whether it's worth mentioning this in detail. > > Thanks, > Alan. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 04:26:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16221 for ; Wed, 17 Oct 2001 04:26:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16029; Wed, 17 Oct 2001 04:03:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15998 for ; Wed, 17 Oct 2001 04:03:10 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15975 for ; Wed, 17 Oct 2001 04:03:09 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 17 Oct 2001 08:03:13 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Oct 2001 09:04:23 +0100 From: "James Undery" To: "Sean Olson \(EUS\)" , Subject: RE: [Sip] Call-Info: header Date: Wed, 17 Oct 2001 09:04:24 +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.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 17 Oct 2001 08:04:23.0597 (UTC) FILETIME=[554075D0:01C156E2] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I for one would oppose this for use with REGISTER as it is bad enough without using it to upload scripts, a separate method like PUBLISH proposed by Steve Donovan is better. As for the matter of sending URLs in other methods I'd prefer a different syntax purely to escape the REGISTER heritage. James -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sean Olson (EUS) Sent: 16 October 2001 19:18 To: 'sip@ietf.org' Subject: [Sip] Call-Info: header Hi, I'm sure this has been discussed before. I don't want to re-open a discussion if a conclusion has been made. In draft-lennox-sip-reg-payload-01.txt, it was proposed to extend the list of disposition-types for the Content-Disposition: header to include "script". I would like to make a similar proposal to extend the list of "purpose" tokens for Call-Info: to include script. The Call-Info: header could then contain a URL to something like a vxml script which could be optionally processed by the receiving party. Because the current syntax allows a token for this parameter, there isn't technically a need to standardize this, but I was wondering if there were strong opinions either way about including this in the bis draft? Regards, Sean Olson Ericsson Inc. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 05:03:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16556 for ; Wed, 17 Oct 2001 05:03:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15616; Wed, 17 Oct 2001 03:58:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15588 for ; Wed, 17 Oct 2001 03:58:33 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15864 for ; Wed, 17 Oct 2001 03:58:32 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9H7x9f05644 for ; Wed, 17 Oct 2001 10:59:09 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Oct 2001 10:58:21 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VFQWN>; Wed, 17 Oct 2001 10:58:03 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC35@esebe013.NOE.Nokia.com> To: brett@broadsoft.com, ajaych@windows.microsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Wed, 17 Oct 2001 10:57:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Comment inline. > > In the following scenario with multiple proxies, each of the > > proxies can challenge the request from the client and the > > client will probably have to respond to the challenges from > > different proxies using different Proxy-Authorization headers > > in the same request. How do the proxies differentiate between > > the different Proxy-Authorization headers and use the right > > header that was meant for the proxy. I was wondering if there > > was a standard way to do this. > > > > C1 ---------> P1 ------------> P2 ---------------> C2 > > > > The realm can be used if the proxy is > certain that it is unique to the proxy. > Otherwise, the nonce can be generated/parsed > in a way that uniquely identifies the > appropriate proxy. The realm only works for Digest authentication. I suppose at least in Basic authentication, the proxy could just pick the topmost Proxy-Authorization and process that. Cheers, Aki _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 09:22:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23425 for ; Wed, 17 Oct 2001 09:22:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24295; Wed, 17 Oct 2001 09:01:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24248 for ; Wed, 17 Oct 2001 09:01:11 -0400 (EDT) Received: from daimanta.ascend.com ([152.148.40.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22251 for ; Wed, 17 Oct 2001 09:01:09 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id JAA08053; Wed, 17 Oct 2001 09:00:34 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id IAA25561; Wed, 17 Oct 2001 08:32:07 -0400 (EDT) Message-ID: <3BCD80F0.939C29D4@lucent.com> Date: Wed, 17 Oct 2001 09:00:32 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: John.Hearty@level3.com, alan.johnston@wcom.com, sean.olson@ericsson.com, sip@ietf.org Subject: Re: [Sip] Alert-Info: header References: <17052388D394D411803900508BDFFAF601B36F7F@n0214idc1.oss.level3.com> <3BCCF348.9277649E@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: [Deleted] > See earlier message about spam. In some cases, even if you allow random > URLs, this can actually help. If I hear the local [your least favorite > telephone company here] jingle, I will press the deep-six (603) button > without bothering to lift the receiver. It is somewhat unfortunate that > existing SIP phones don't have this button... > SPAM is not the major issue with the header as far as I see it. * Harrassment The phone 'rings' with "I'm watching you..." (Spoofed UDP INVITE that points to movie/TV sound web archive in Alert-Info, or free/anonymous web-hosting site.) * Mischief The phone 'rings' with the sound of a fire alarm and someone shouting 'Fire! Someone pull the fire alarm!' (Spoofed UDP INVITE that points to movie/TV sound web archive in Alert-Info, or free web-hosting site.) * Serious mischief The phone 'rings' at a police station or such with 'Look out! He's got a gun!' * DOS Multiple phones in a building are sent INVITEs with Alert-Info pointing to 'wav' file that is 10 gigabytes long, tying up the bandwidth until the network admin can track down which unattended phones/IP addresses are doing this and kill off the connections. * Security issues If a helper application (i.e. your favorite web browser or media player) is used to deal with the information in the Alert-Info header, then this opens up a potential line of attack for things like those script viruses, buffer overflows, etc. All the vulnerabilities that have been experienced to date with certain email and browser programs. (It should be noted that in this case, even having a trust relationship with the calling party may not be enough if the calling party has gotten infected with a virus/trojan that spreads itself by calling everyone in the address/phone book with itself in the Alert-Info header. The call will appear to have been from a trusted party.) If there is no helper application for dealing with various types of media files, then the phone itself will have to support them -- .wav, .au, .wma, .mp3, .jpg, .avi, .mov, .vbs, etc. etc. whatever. That's not saying these are untraceable or unstoppable, but it seems like the header pretty much cannot be used without a very strong security relationship in place between the two parties, and even that may fail in the last case. (Even if people who attempt such things as the above are caught, there are always plenty of idiots who try such things because they do not think they will be caught. The damage caused by such things needs to be prevented in the first place, though.) Even only allowing for 'local ring tone' URLs, those within the provider's domain, is probably not strong enough. If some party A in the domain has a 'private' sound file party A uses with party B, but party C learns what the URL is, then party C can call party D (if D is on the same provider) specifying party A's ring tone. The 'local ring tone' seems a bit odd for the calling party to use -- the calling party would have to specify a different URL in the Alert-Info depending on who was being called to refer to the apropriate local ring tone for the called party's provider. At that point it sounds like it would just make more sense for the called party to have set up a local profile with distinctive ringtones based on the calling party, and letting the calling party send over a ring tone out of band. If the question boils down to "Should an arbitrary URL be used as a ring tone without the called party's *explicit* consent?" (emphasis on explicit), then, well, the Alert-Info seems pretty useless. The called party will have to have configured what is and is not allowable for which parties, which would tend to lean towards a local distinctive ring feature, not a "caller specified ring" parameter. At best, perhaps a , , , etc. type use of the Alert-Info header, to let a trusted, known calling party specify a specific named ring configured by the called party. (i.e. the user configures his phone such that , if called by Bob, translates to if desired, or when called by Joe, translates to ) -- Kim Liu kliu@lucent.com : Everyone is a darn fool for at Senior Software Engineer : least five minutes a day; Lucent Technologies : wisdom consists of not Clearwater, FL, 33761 : exceeding the limit _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 10:59:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26707 for ; Wed, 17 Oct 2001 10:59:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26418; Wed, 17 Oct 2001 10:24:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26315 for ; Wed, 17 Oct 2001 10:24:49 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25820 for ; Wed, 17 Oct 2001 10:24:46 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9HEOJ022441 for ; Wed, 17 Oct 2001 09:24:19 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9HEOJU22720 for ; Wed, 17 Oct 2001 09:24:19 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Oct 17 09:24:19 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CQDX8A2>; Wed, 17 Oct 2001 09:24:19 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'John.Hearty@Level3.com'" , alan.johnston@wcom.com, hgs@cs.columbia.edu Cc: sip@ietf.org Subject: RE: [Sip] Alert-Info: header Date: Wed, 17 Oct 2001 09:24:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15717.67D37460" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C15717.67D37460 Content-Type: text/plain; charset="iso-8859-1" This is a point well taken. I wanted to generalize the header to allow for a variety of cool new features. If extending this header is not an option, could we propose a new header for this purpose? (preferably a general header). I personally don't understand the problem with using this header for "ringback" if you are allowing it for "ring tone". With regards to spam, you must be very careful in both directions. But then again, you must be very careful about accepting an INVITE as well which has a larger potential for spam. (not to mention MESSAGE) Sean Olson Ericsson Inc. > I think using the header for both purposes is overloading it. > The idea is >good, but a different header should be used. Good point on >the spam! That >might wind up killing the intended functionality from getting >implemented. > >John Hearty >Level3 > >-----Original Message----- >From: Alan Johnston [mailto:alan.johnston@wcom.com] >Sent: Tuesday, October 16, 2001 4:51 PM >To: Henning G. Schulzrinne >Cc: Sean Olson (EUS); 'sip@ietf.org' >Subject: Re: [Sip] Alert-Info: header > > >Henning, > >So are you opposed to the use of this header as Sean describes >it? The >use >of the header for personalized ringback without resorting to >early media is >a >good idea. > >As for its use in distinctive ringing, we'll just need a note >to say that >the >use of this header requires the strongest security and trust >relationship >otherwise it will be the cause of the worst kind of SPAM. > >Thanks, >Alan. > >"Henning G. Schulzrinne" wrote: > >> Alan Johnston wrote: >> > >> > Sean, >> > >> > I have always assumed that the Alert-Info header being listed as a >> > Request header was an error - it only makes sense for it >to be used as >> > you describe - in a response (180 Ringing, to be specific, >since this is >> > the only SIP response that tells the UAC to play ringback >tone to the >> > caller). >> > >> > This then allows a UAS to deliver a customizable ringback >tone without >> > resorting to early media. >> >> This is for *ring* tone, not *ringback* tone. >> >> > >> > The use of Alert-Info in an INVITE never made any sense to >me. There >> > would be a delay in the UAS from the receipt of the INVITE >until it had >> > fetched the alert sound. Then, assuming that the UAS >played the sound, >> > how would the user even know that his SIP phone or client >was ringing? >> > >> >> The delay would often be minuscule (a second or less), in >particular if >> the Alert-Info is inserted by the local proxy on the receiving side >> (e.g., to do caller-dependent ring tones). >> >> I don't understand the last question. If the URL is sound, the callee >> would hear it... >> >> > Used the other way around, the header does not introduce a >delay in the >> > session setup (a delay of audible ringback while the UAC >fetches the >> > ringback sound does not delay the UAS answering), and the >caller just >> > hears a different sound besides ringing, something >perfectly possible >> > with early media, but handled in a much more efficient way >using this >> > header. >> > >> > This is how this header will be described in bis-05, so >let me know if I >> > am totally off base here. >> >> Yes, unfortunately. >> >> > >> > Thanks, >> > Alan Johnston >> > WorldCom >> > sip:alan@siptest.wcom.com >> > >> > "Sean Olson (EUS)" wrote: >> > >> p >> >> -- >> Henning Schulzrinne http://www.cs.columbia.edu/~hgs >> >> _______________________________________________ >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C15717.67D37460 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Alert-Info: header

This is a point well taken. I wanted to generalize the
header to allow for a variety of cool new features. If
extending this header is not an option, could we propose
a new header for this purpose? (preferably a general header).
I personally don't understand the problem with using this
header for "ringback" if you are allowing it for "ring tone".

With regards to spam, you must be very careful in both directions.
But then again, you must be very careful about accepting an INVITE
as well which has a larger potential for spam. (not to mention
MESSAGE)

Sean Olson
Ericsson Inc.

> I think using the header for both purposes is overloading it.
> The idea is
>good, but a different header should be used.  Good point on
>the spam!  That
>might wind up killing the intended functionality from getting
>implemented.
>
>John Hearty
>Level3
>
>-----Original Message-----
>From: Alan Johnston [mailto:alan.johnston@wcom.com]
>Sent: Tuesday, October 16, 2001 4:51 PM
>To: Henning G. Schulzrinne
>Cc: Sean Olson (EUS); 'sip@ietf.org'
>Subject: Re: [Sip] Alert-Info: header
>
>
>Henning,
>
>So are you opposed to the use of this header as Sean describes
>it?    The
>use
>of the header for personalized ringback without resorting to
>early media is
>a
>good idea.
>
>As for its use in distinctive ringing, we'll just need a note
>to say that
>the
>use of this header requires the strongest security and trust
>relationship
>otherwise it will be the cause of the worst kind of SPAM.
>
>Thanks,
>Alan.
>
>"Henning G. Schulzrinne" wrote:
>
>> Alan Johnston wrote:
>> >
>> > Sean,
>> >
>> > I have always assumed that the Alert-Info header being listed as a
>> > Request header was an error - it only makes sense for it
>to be used as
>> > you describe - in a response (180 Ringing, to be specific,
>since this is
>> > the only SIP response that tells the UAC to play ringback
>tone to the
>> > caller).
>> >
>> > This then allows a UAS to deliver a customizable ringback
>tone without
>> > resorting to early media.
>>
>> This is for *ring* tone, not *ringback* tone.
>>
>> >
>> > The use of Alert-Info in an INVITE never made any sense to
>me.  There
>> > would be a delay in the UAS from the receipt of the INVITE
>until it had
>> > fetched the alert sound.  Then, assuming that the UAS
>played the sound,
>> > how would the user even know that his SIP phone or client
>was ringing?
>> >
>>
>> The delay would often be minuscule (a second or less), in
>particular if
>> the Alert-Info is inserted by the local proxy on the receiving side
>> (e.g., to do caller-dependent ring tones).
>>
>> I don't understand the last question. If the URL is sound, the callee
>> would hear it...
>>
>> > Used the other way around, the header does not introduce a
>delay in the
>> > session setup (a delay of audible ringback while the UAC
>fetches the
>> > ringback sound does not delay the UAS answering), and the
>caller just
>> > hears a different sound besides ringing, something
>perfectly possible
>> > with early media, but handled in a much more efficient way
>using this
>> > header.
>> >
>> > This is how this header will be described in bis-05, so
>let me know if I
>> > am totally off base here.
>>
>> Yes, unfortunately.
>>
>> >
>> > Thanks,
>> > Alan Johnston
>> > WorldCom
>> > sip:alan@siptest.wcom.com
>> >
>> > "Sean Olson (EUS)" wrote:
>> >
>> p
>>
>> --
>> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>>
>> _______________________________________________
>> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>

------_=_NextPart_001_01C15717.67D37460-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 11:19:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27258 for ; Wed, 17 Oct 2001 11:19:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27471; Wed, 17 Oct 2001 10:53:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27431 for ; Wed, 17 Oct 2001 10:53:24 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26549 for ; Wed, 17 Oct 2001 10:53:23 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9HEqu009794 for ; Wed, 17 Oct 2001 09:52:56 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9HEquU11529 for ; Wed, 17 Oct 2001 09:52:56 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Oct 17 09:52:07 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP0B0HC>; Wed, 17 Oct 2001 09:52:06 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'James Undery'" , sip@ietf.org Subject: RE: [Sip] Call-Info: header Date: Wed, 17 Oct 2001 09:52:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1571B.48C3CE90" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1571B.48C3CE90 Content-Type: text/plain; charset="iso-8859-1" >Hi, > >I for one would oppose this for use with REGISTER as it is bad enough >without using it to upload scripts, a separate method like PUBLISH >proposed by Steve Donovan is better. I agree entirely. I am not trying to solve the PUBLISH problem (as I understand it). I would expect this header really only to be used in the INVITE and 200 OK. (Possibly the ACK as well, but that would be a stretch). This is really meant to be used in the context of distributed application components where you are trying to convey a URL for a script that a component needs to perform its job. Make sense? > >As for the matter of sending URLs in other methods I'd prefer a >different syntax purely to escape the REGISTER heritage. A different syntax than a URL? Or a different syntax than the Call-Info: header? >James /sean >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sean >Olson (EUS) >Sent: 16 October 2001 19:18 >To: 'sip@ietf.org' >Subject: [Sip] Call-Info: header > > >Hi, >I'm sure this has been discussed before. I don't >want to re-open a discussion if a conclusion has >been made. In draft-lennox-sip-reg-payload-01.txt, >it was proposed to extend the list of disposition-types for >the Content-Disposition: header to include "script". >I would like to make a similar proposal to extend >the list of "purpose" tokens for Call-Info: to include >script. The Call-Info: header could then contain a >URL to something like a vxml script which could be >optionally processed by the receiving party. >Because the current syntax allows a token for this >parameter, there isn't technically a need to standardize >this, but I was wondering if there were strong opinions >either way about including this in the bis draft? >Regards, >Sean Olson >Ericsson Inc. > ------_=_NextPart_001_01C1571B.48C3CE90 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Call-Info: header

>Hi,
>
>I for one would oppose this for use with REGISTER as it is bad enough
>without using it to upload scripts, a separate method like PUBLISH
>proposed by Steve Donovan is better.

I agree entirely. I am not trying to solve the PUBLISH problem (as
I understand it). I would expect this header really only to be
used in the INVITE and 200 OK. (Possibly the ACK as well, but that
would be a stretch). This is really meant to be used in the context
of distributed application components where you are trying to
convey a URL for a script that a component needs to perform its job.
Make sense?

>
>As for the matter of sending URLs in other methods I'd prefer a
>different syntax purely to escape the REGISTER heritage.

A different syntax than a URL? Or a different syntax than the Call-Info:
header?

>James

/sean

>-----Original Message-----
>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sean
>Olson (EUS)
>Sent: 16 October 2001 19:18
>To: 'sip@ietf.org'
>Subject: [Sip] Call-Info: header
>
>
>Hi,
>I'm sure this has been discussed before. I don't
>want to re-open a discussion if a conclusion has
>been made. In draft-lennox-sip-reg-payload-01.txt,
>it was proposed to extend the list of disposition-types for
>the Content-Disposition: header to include "script".
>I would like to make a similar proposal to extend
>the list of "purpose" tokens for Call-Info: to include
>script. The Call-Info: header could then contain a
>URL to something like a vxml script which could be
>optionally processed by the receiving party.
>Because the current syntax allows a token for this
>parameter, there isn't technically a need to standardize
>this, but I was wondering if there were strong opinions
>either way about including this in the bis draft?
>Regards,
>Sean Olson
>Ericsson Inc.
>

------_=_NextPart_001_01C1571B.48C3CE90-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 11:47:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27890 for ; Wed, 17 Oct 2001 11:47:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28188; Wed, 17 Oct 2001 11:21:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28157 for ; Wed, 17 Oct 2001 11:21:08 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27294 for ; Wed, 17 Oct 2001 11:21:06 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 17 Oct 2001 15:21:10 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Oct 2001 16:22:21 +0100 From: "James Undery" To: "Sean Olson \(EUS\)" , Subject: RE: [Sip] Call-Info: header Date: Wed, 17 Oct 2001 16:22:22 +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.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 17 Oct 2001 15:22:21.0704 (UTC) FILETIME=[84396080:01C1571F] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The problem here is related though, the awkwardness is for the case when the Request partially succeeded, i.e. The INVITE is fine, but I didn't like the script. Do you 4xx the request and how do you indicate the cause in a consistent manner (Warning headers are more aimed at presentation of errors to a user). If you just ignore failed scripts I don't think you'll have the effect you desire. Unfortunately I can't think of a constructive suggestion to implement the functionality you're after in a way that'd make me happy. I meant the Call-Info parameter, but on reflection, as it's a different header I can't see what I was worried about. James -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: 17 October 2001 15:52 To: 'James Undery'; sip@ietf.org Subject: RE: [Sip] Call-Info: header >Hi, > >I for one would oppose this for use with REGISTER as it is bad enough >without using it to upload scripts, a separate method like PUBLISH >proposed by Steve Donovan is better. I agree entirely. I am not trying to solve the PUBLISH problem (as I understand it). I would expect this header really only to be used in the INVITE and 200 OK. (Possibly the ACK as well, but that would be a stretch). This is really meant to be used in the context of distributed application components where you are trying to convey a URL for a script that a component needs to perform its job. Make sense? > >As for the matter of sending URLs in other methods I'd prefer a >different syntax purely to escape the REGISTER heritage. A different syntax than a URL? Or a different syntax than the Call-Info: header? >James /sean >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sean >Olson (EUS) >Sent: 16 October 2001 19:18 >To: 'sip@ietf.org' >Subject: [Sip] Call-Info: header > > >Hi, >I'm sure this has been discussed before. I don't >want to re-open a discussion if a conclusion has >been made. In draft-lennox-sip-reg-payload-01.txt, >it was proposed to extend the list of disposition-types for >the Content-Disposition: header to include "script". >I would like to make a similar proposal to extend >the list of "purpose" tokens for Call-Info: to include >script. The Call-Info: header could then contain a >URL to something like a vxml script which could be >optionally processed by the receiving party. >Because the current syntax allows a token for this >parameter, there isn't technically a need to standardize >this, but I was wondering if there were strong opinions >either way about including this in the bis draft? >Regards, >Sean Olson >Ericsson Inc. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 12:11:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28751 for ; Wed, 17 Oct 2001 12:11:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28983; Wed, 17 Oct 2001 11:40:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28952 for ; Wed, 17 Oct 2001 11:40:02 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27734 for ; Wed, 17 Oct 2001 11:40:00 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9HFe3Y00789 for ; Wed, 17 Oct 2001 10:40:04 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9HFe3U15250 for ; Wed, 17 Oct 2001 10:40:03 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Oct 17 10:38:21 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CQDYD65>; Wed, 17 Oct 2001 10:38:21 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'James Undery'" , sip@ietf.org Subject: RE: [Sip] Call-Info: header Date: Wed, 17 Oct 2001 10:38:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15721.BFFED210" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C15721.BFFED210 Content-Type: text/plain; charset="iso-8859-1" Hello, The problem you mention comes from a lack of a response code in SIP to express what you want. In general, what has happened is that a server is attempting to execute some service logic and that logic is "broken". How should the server respond to the request? This same problem could occur for SIP-CGI, SIP servlets, SIN, etc. How about a new "514 Service Failure" response code? I would also be happy returning a generic 500 response code in this situation. Thoughts? /sean >-----Original Message----- >From: James Undery [mailto:jundery@ubiquity.net] >Sent: Wednesday, October 17, 2001 10:22 AM >To: Sean Olson (EUS); sip@ietf.org >Subject: RE: [Sip] Call-Info: header > > >Hi, > >The problem here is related though, the awkwardness is for the case >when the Request partially succeeded, i.e. The INVITE is fine, but I >didn't like the script. Do you 4xx the request and how do you indicate >the cause in a consistent manner (Warning headers are more aimed at >presentation of errors to a user). If you just ignore failed scripts I >don't think you'll have the effect you desire. Unfortunately I can't >think of a constructive suggestion to implement the functionality >you're after in a way that'd make me happy. > >I meant the Call-Info parameter, but on reflection, as it's a >different header I can't see what I was worried about. > >James > >-----Original Message----- >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] >Sent: 17 October 2001 15:52 >To: 'James Undery'; sip@ietf.org >Subject: RE: [Sip] Call-Info: header > > > > >>Hi, >> >>I for one would oppose this for use with REGISTER as it is bad enough >>without using it to upload scripts, a separate method like PUBLISH >>proposed by Steve Donovan is better. >I agree entirely. I am not trying to solve the PUBLISH problem (as >I understand it). I would expect this header really only to be >used in the INVITE and 200 OK. (Possibly the ACK as well, but that >would be a stretch). This is really meant to be used in the context >of distributed application components where you are trying to >convey a URL for a script that a component needs to perform its job. >Make sense? >> >>As for the matter of sending URLs in other methods I'd prefer a >>different syntax purely to escape the REGISTER heritage. >A different syntax than a URL? Or a different syntax than the >Call-Info: >header? >>James >/sean >>-----Original Message----- >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sean >>Olson (EUS) >>Sent: 16 October 2001 19:18 >>To: 'sip@ietf.org' >>Subject: [Sip] Call-Info: header >> >> >>Hi, >>I'm sure this has been discussed before. I don't >>want to re-open a discussion if a conclusion has >>been made. In draft-lennox-sip-reg-payload-01.txt, >>it was proposed to extend the list of disposition-types for >>the Content-Disposition: header to include "script". >>I would like to make a similar proposal to extend >>the list of "purpose" tokens for Call-Info: to include >>script. The Call-Info: header could then contain a >>URL to something like a vxml script which could be >>optionally processed by the receiving party. >>Because the current syntax allows a token for this >>parameter, there isn't technically a need to standardize >>this, but I was wondering if there were strong opinions >>either way about including this in the bis draft? >>Regards, >>Sean Olson >>Ericsson Inc. >> > ------_=_NextPart_001_01C15721.BFFED210 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Call-Info: header

Hello,

The problem you mention comes from a lack of a
response code in SIP to express what you want.
In general, what has happened is that a server
is attempting to execute some service logic and
that logic is "broken". How should the server
respond to the request? This same problem could
occur for SIP-CGI, SIP servlets, SIN, etc.

How about a new "514 Service Failure" response code?
I would also be happy returning a generic 500 response
code in this situation.

Thoughts?
/sean

>-----Original Message-----
>From: James Undery [mailto:jundery@ubiquity.net]
>Sent: Wednesday, October 17, 2001 10:22 AM
>To: Sean Olson (EUS); sip@ietf.org
>Subject: RE: [Sip] Call-Info: header
>
>
>Hi,
>
>The problem here is related though, the awkwardness is for the case
>when the Request partially succeeded, i.e. The INVITE is fine, but I
>didn't like the script. Do you 4xx the request and how do you indicate
>the cause in a consistent manner (Warning headers are more aimed at
>presentation of errors to a user). If you just ignore failed scripts I
>don't think you'll have the effect you desire. Unfortunately I can't
>think of a constructive suggestion to implement the functionality
>you're after in a way that'd make me happy.
>
>I meant the Call-Info parameter, but on reflection, as it's a
>different header I can't see what I was worried about.
>
>James
>
>-----Original Message-----
>From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
>Sent: 17 October 2001 15:52
>To: 'James Undery'; sip@ietf.org
>Subject: RE: [Sip] Call-Info: header
>
>
>
>
>>Hi,
>>
>>I for one would oppose this for use with REGISTER as it is bad enough
>>without using it to upload scripts, a separate method like PUBLISH
>>proposed by Steve Donovan is better.
>I agree entirely. I am not trying to solve the PUBLISH problem (as
>I understand it). I would expect this header really only to be
>used in the INVITE and 200 OK. (Possibly the ACK as well, but that
>would be a stretch). This is really meant to be used in the context
>of distributed application components where you are trying to
>convey a URL for a script that a component needs to perform its job.
>Make sense?
>>
>>As for the matter of sending URLs in other methods I'd prefer a
>>different syntax purely to escape the REGISTER heritage.
>A different syntax than a URL? Or a different syntax than the
>Call-Info:
>header?
>>James
>/sean
>>-----Original Message-----
>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sean
>>Olson (EUS)
>>Sent: 16 October 2001 19:18
>>To: 'sip@ietf.org'
>>Subject: [Sip] Call-Info: header
>>
>>
>>Hi,
>>I'm sure this has been discussed before. I don't
>>want to re-open a discussion if a conclusion has
>>been made. In draft-lennox-sip-reg-payload-01.txt,
>>it was proposed to extend the list of disposition-types for
>>the Content-Disposition: header to include "script".
>>I would like to make a similar proposal to extend
>>the list of "purpose" tokens for Call-Info: to include
>>script. The Call-Info: header could then contain a
>>URL to something like a vxml script which could be
>>optionally processed by the receiving party.
>>Because the current syntax allows a token for this
>>parameter, there isn't technically a need to standardize
>>this, but I was wondering if there were strong opinions
>>either way about including this in the bis draft?
>>Regards,
>>Sean Olson
>>Ericsson Inc.
>>
>

------_=_NextPart_001_01C15721.BFFED210-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 12:23:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29191 for ; Wed, 17 Oct 2001 12:23:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29670; Wed, 17 Oct 2001 12:00:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29414 for ; Wed, 17 Oct 2001 12:00:00 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28231 for ; Wed, 17 Oct 2001 11:59:58 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 17 Oct 2001 16:00:03 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Oct 2001 17:01:15 +0100 From: "James Undery" To: "Sean Olson \(EUS\)" , Subject: RE: [Sip] Call-Info: header Date: Wed, 17 Oct 2001 17:01:15 +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.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 17 Oct 2001 16:01:15.0122 (UTC) FILETIME=[F30CB520:01C15724] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, My gut feeling is that it is different from SIP-CGI etc, where a 5xx is appropriate. The reasons for this are, firstly Call-Info is more of a hint and secondly it just feels more like 4xx rather than a server failure. On reflection I'd be happier with a new header specifying the script's URL and a level of importance, combined with a Require header if the script is cruicial. The level of importance could indicate if the request should fail if the script does or just continue regardless. James -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Hello, The problem you mention comes from a lack of a response code in SIP to express what you want. In general, what has happened is that a server is attempting to execute some service logic and that logic is "broken". How should the server respond to the request? This same problem could occur for SIP-CGI, SIP servlets, SIN, etc. How about a new "514 Service Failure" response code? I would also be happy returning a generic 500 response code in this situation. Thoughts? /sean >-----Original Message----- >From: James Undery [mailto:jundery@ubiquity.net] >Sent: Wednesday, October 17, 2001 10:22 AM >To: Sean Olson (EUS); sip@ietf.org >Subject: RE: [Sip] Call-Info: header > > >Hi, > >The problem here is related though, the awkwardness is for the case >when the Request partially succeeded, i.e. The INVITE is fine, but I >didn't like the script. Do you 4xx the request and how do you indicate >the cause in a consistent manner (Warning headers are more aimed at >presentation of errors to a user). If you just ignore failed scripts I >don't think you'll have the effect you desire. Unfortunately I can't >think of a constructive suggestion to implement the functionality >you're after in a way that'd make me happy. > >I meant the Call-Info parameter, but on reflection, as it's a >different header I can't see what I was worried about. > >James _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 13:21:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00653 for ; Wed, 17 Oct 2001 13:21:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01964; Wed, 17 Oct 2001 12:38:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01932 for ; Wed, 17 Oct 2001 12:38:40 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29711 for ; Wed, 17 Oct 2001 12:38:40 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9HGcfY18294 for ; Wed, 17 Oct 2001 11:38:41 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9HGcfB09873 for ; Wed, 17 Oct 2001 11:38:41 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Oct 17 11:38:29 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CQDYJXN>; Wed, 17 Oct 2001 11:38:29 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'James Undery'" , sip@ietf.org Subject: RE: [Sip] Call-Info: header Date: Wed, 17 Oct 2001 11:38:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1572A.26453FC0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1572A.26453FC0 Content-Type: text/plain; charset="iso-8859-1" How about: Service-Info = "Service-Info" ":" (1# (addr-spec) *(";" service-params)) service-params = "q" "=" qvalue | "onerror" "=" "continue" | "halt" | generic-param Use the q-value to order 1 or more scripts. Use a "Require: inline-service" to mandate support if needed. The "onerror" parameter specified what to do in the event of an error in processing the script. Thinking about this a little more, this is exactly the problem of PUBLISHing a CPL script, so perhaps it is best to wait for those requirements to firm up before suggesting a mechanism. I would like to propose the requirement that we be able to specify this service related information on a per-INVITE (or actually per-request) basis. An adjunct requirement would be to allow specification of service related information on a call leg basis. /sean >-----Original Message----- >From: James Undery [mailto:jundery@ubiquity.net] >Sent: Wednesday, October 17, 2001 11:01 AM >To: Sean Olson (EUS); sip@ietf.org >Subject: RE: [Sip] Call-Info: header > > >Hi, > >My gut feeling is that it is different from SIP-CGI etc, where a 5xx >is appropriate. The reasons for this are, firstly Call-Info is more of >a hint and secondly it just feels more like 4xx rather than a server >failure. On reflection I'd be happier with a new header specifying the >script's URL and a level of importance, combined with a Require header >if the script is cruicial. The level of importance could indicate if >the request should fail if the script does or just continue >regardless. > >James > > >-----Original Message----- >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > >Hello, >The problem you mention comes from a lack of a >response code in SIP to express what you want. >In general, what has happened is that a server >is attempting to execute some service logic and >that logic is "broken". How should the server >respond to the request? This same problem could >occur for SIP-CGI, SIP servlets, SIN, etc. >How about a new "514 Service Failure" response code? >I would also be happy returning a generic 500 response >code in this situation. >Thoughts? >/sean >>-----Original Message----- >>From: James Undery [mailto:jundery@ubiquity.net] >>Sent: Wednesday, October 17, 2001 10:22 AM >>To: Sean Olson (EUS); sip@ietf.org >>Subject: RE: [Sip] Call-Info: header >> >> >>Hi, >> >>The problem here is related though, the awkwardness is for the case >>when the Request partially succeeded, i.e. The INVITE is fine, but I >>didn't like the script. Do you 4xx the request and how do you >indicate >>the cause in a consistent manner (Warning headers are more aimed at >>presentation of errors to a user). If you just ignore failed scripts >I >>don't think you'll have the effect you desire. Unfortunately I can't >>think of a constructive suggestion to implement the functionality >>you're after in a way that'd make me happy. >> >>I meant the Call-Info parameter, but on reflection, as it's a >>different header I can't see what I was worried about. >> >>James > ------_=_NextPart_001_01C1572A.26453FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Call-Info: header

How about:

Service-Info =3D "Service-Info" = ":"
          &nb= sp;    (1# (addr-spec)
          &nb= sp;    *(";" service-params))

service-params =3D "q" "=3D" = qvalue
          &nb= sp;    | "onerror" "=3D" = "continue" | "halt"
          &nb= sp;    | generic-param

Use the q-value to order 1 or more scripts.
Use a "Require: inline-service" to mandate = support
if needed.
The "onerror" parameter specified what to = do in the event
of an error in processing the script.

Thinking about this a little more, this is = exactly
the problem of PUBLISHing a CPL script, so = perhaps
it is best to wait for those requirements to firm = up
before suggesting a mechanism.

I would like to propose the requirement that = we
be able to specify this service related = information
on a per-INVITE (or actually per-request) = basis.
An adjunct requirement would be to allow = specification
of service related information on a call leg = basis.

/sean

>-----Original Message-----
>From: James Undery [mailto:jundery@ubiquity.net]
>Sent: Wednesday, October 17, 2001 11:01 = AM
>To: Sean Olson (EUS); sip@ietf.org
>Subject: RE: [Sip] Call-Info: header
>
>
>Hi,
>
>My gut feeling is that it is different from = SIP-CGI etc, where a 5xx
>is appropriate. The reasons for this are, = firstly Call-Info is more of
>a hint and secondly it just feels more like 4xx = rather than a server
>failure. On reflection I'd be happier with a new = header specifying the
>script's URL and a level of importance, combined = with a Require header
>if the script is cruicial. The level of = importance could indicate if
>the request should fail if the script does or = just continue
>regardless.
>
>James
>
>
>-----Original Message-----
>From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
>
>Hello,
>The problem you mention comes from a lack of = a
>response code in SIP to express what you want.
>In general, what has happened is that a = server
>is attempting to execute some service logic = and
>that logic is "broken". How should the = server
>respond to the request? This same problem = could
>occur for SIP-CGI, SIP servlets, SIN, = etc.
>How about a new "514 Service Failure" = response code?
>I would also be happy returning a generic 500 = response
>code in this situation.
>Thoughts?
>/sean
>>-----Original Message-----
>>From: James Undery [mailto:jundery@ubiquity.net]
>>Sent: Wednesday, October 17, 2001 10:22 = AM
>>To: Sean Olson (EUS); sip@ietf.org
>>Subject: RE: [Sip] Call-Info: header
>>
>>
>>Hi,
>>
>>The problem here is related though, the = awkwardness is for the case
>>when the Request partially succeeded, i.e. = The INVITE is fine, but I
>>didn't like the script. Do you 4xx the = request and how do you
>indicate
>>the cause in a consistent manner (Warning = headers are more aimed at
>>presentation of errors to a user). If you = just ignore failed scripts
>I
>>don't think you'll have the effect you = desire. Unfortunately I can't
>>think of a constructive suggestion to = implement the functionality
>>you're after in a way that'd make me = happy.
>>
>>I meant the Call-Info parameter, but on = reflection, as it's a
>>different header I can't see what I was = worried about.
>>
>>James
>

------_=_NextPart_001_01C1572A.26453FC0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 16:50:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07248 for ; Wed, 17 Oct 2001 16:50:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08256; Wed, 17 Oct 2001 16:22:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08225 for ; Wed, 17 Oct 2001 16:22:29 -0400 (EDT) Received: from smtpout.ev1.net (smtpout.ev1.net [207.218.192.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06560 for ; Wed, 17 Oct 2001 16:22:27 -0400 (EDT) Received: from rioa1475 [208.187.66.38] by smtpout.ev1.net (SMTPD32-6.06) id A84D901800A4; Wed, 17 Oct 2001 15:21:33 -0500 Message-ID: <00ac01c15749$8961c640$2642bbd0@rioa1475> Reply-To: "Mart Nurmet" From: "Mart Nurmet" To: "Sean Olson \(EUS\)" Cc: References: Subject: Re: [Sip] Alert-Info: header Date: Wed, 17 Oct 2001 15:23:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01C1571F.9F55FD60" 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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C1571F.9F55FD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Alert-Info: headerSean et all: This does not seem to have that much consensus. John's point would be = better served. =20 -Mart ----- Original Message -----=20 From: Sean Olson (EUS)=20 To: 'John.Hearty@Level3.com' ; alan.johnston@wcom.com ; = hgs@cs.columbia.edu=20 Cc: sip@ietf.org=20 Sent: Wednesday, October 17, 2001 9:24 AM Subject: RE: [Sip] Alert-Info: header This is a point well taken. I wanted to generalize the=20 header to allow for a variety of cool new features. If=20 extending this header is not an option, could we propose=20 a new header for this purpose? (preferably a general header).=20 I personally don't understand the problem with using this=20 header for "ringback" if you are allowing it for "ring tone".=20 With regards to spam, you must be very careful in both directions.=20 But then again, you must be very careful about accepting an INVITE=20 as well which has a larger potential for spam. (not to mention=20 MESSAGE)=20 Sean Olson=20 Ericsson Inc.=20 > I think using the header for both purposes is overloading it.=20 > The idea is=20 >good, but a different header should be used. Good point on=20 >the spam! That=20 >might wind up killing the intended functionality from getting=20 >implemented.=20 >=20 >John Hearty=20 >Level3=20 >=20 >-----Original Message-----=20 >From: Alan Johnston [mailto:alan.johnston@wcom.com]=20 >Sent: Tuesday, October 16, 2001 4:51 PM=20 >To: Henning G. Schulzrinne=20 >Cc: Sean Olson (EUS); 'sip@ietf.org'=20 >Subject: Re: [Sip] Alert-Info: header=20 >=20 >=20 >Henning,=20 >=20 >So are you opposed to the use of this header as Sean describes=20 >it? The=20 >use=20 >of the header for personalized ringback without resorting to=20 >early media is=20 >a=20 >good idea.=20 >=20 >As for its use in distinctive ringing, we'll just need a note=20 >to say that=20 >the=20 >use of this header requires the strongest security and trust=20 >relationship=20 >otherwise it will be the cause of the worst kind of SPAM.=20 >=20 >Thanks,=20 >Alan.=20 >=20 >"Henning G. Schulzrinne" wrote:=20 >=20 >> Alan Johnston wrote:=20 >> >=20 >> > Sean,=20 >> >=20 >> > I have always assumed that the Alert-Info header being listed as = a=20 >> > Request header was an error - it only makes sense for it=20 >to be used as=20 >> > you describe - in a response (180 Ringing, to be specific,=20 >since this is=20 >> > the only SIP response that tells the UAC to play ringback=20 >tone to the=20 >> > caller).=20 >> >=20 >> > This then allows a UAS to deliver a customizable ringback=20 >tone without=20 >> > resorting to early media.=20 >>=20 >> This is for *ring* tone, not *ringback* tone.=20 >>=20 >> >=20 >> > The use of Alert-Info in an INVITE never made any sense to=20 >me. There=20 >> > would be a delay in the UAS from the receipt of the INVITE=20 >until it had=20 >> > fetched the alert sound. Then, assuming that the UAS=20 >played the sound,=20 >> > how would the user even know that his SIP phone or client=20 >was ringing?=20 >> >=20 >>=20 >> The delay would often be minuscule (a second or less), in=20 >particular if=20 >> the Alert-Info is inserted by the local proxy on the receiving side = >> (e.g., to do caller-dependent ring tones).=20 >>=20 >> I don't understand the last question. If the URL is sound, the = callee=20 >> would hear it...=20 >>=20 >> > Used the other way around, the header does not introduce a=20 >delay in the=20 >> > session setup (a delay of audible ringback while the UAC=20 >fetches the=20 >> > ringback sound does not delay the UAS answering), and the=20 >caller just=20 >> > hears a different sound besides ringing, something=20 >perfectly possible=20 >> > with early media, but handled in a much more efficient way=20 >using this=20 >> > header.=20 >> >=20 >> > This is how this header will be described in bis-05, so=20 >let me know if I=20 >> > am totally off base here.=20 >>=20 >> Yes, unfortunately.=20 >>=20 >> >=20 >> > Thanks,=20 >> > Alan Johnston=20 >> > WorldCom=20 >> > sip:alan@siptest.wcom.com=20 >> >=20 >> > "Sean Olson (EUS)" wrote:=20 >> >=20 >> p=20 >>=20 >> --=20 >> Henning Schulzrinne http://www.cs.columbia.edu/~hgs=20 >>=20 >> _______________________________________________=20 >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip=20 >> This list is for NEW development of the core SIP Protocol=20 >> Use sip-implementors@cs.columbia.edu for questions on current sip=20 >> Use sipping@ietf.org for new developments on the application of sip = >=20 >=20 >_______________________________________________=20 >Sip mailing list http://www1.ietf.org/mailman/listinfo/sip=20 >This list is for NEW development of the core SIP Protocol=20 >Use sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip=20 >=20 ------=_NextPart_000_00A9_01C1571F.9F55FD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Alert-Info: header
Sean et all:
 
This does not seem to have that much=20 consensus.  John's point would be better served.    =
 
-Mart
----- Original Message -----
From:=20 Sean=20 Olson (EUS)
To: 'John.Hearty@Level3.com' ; alan.johnston@wcom.com ; hgs@cs.columbia.edu
Sent: Wednesday, October 17, = 2001 9:24=20 AM
Subject: RE: [Sip] Alert-Info:=20 header

This is a point well taken. I wanted to generalize = the=20
header to allow for a variety of cool new features. = If=20
extending this header is not an option, could we=20 propose
a new header for this purpose? = (preferably a=20 general header).
I personally don't = understand the=20 problem with using this
header for = "ringback" if you=20 are allowing it for "ring tone".

With regards to spam, you must be very careful in = both=20 directions.
But then again, you must be very = careful=20 about accepting an INVITE
as well which has = a larger=20 potential for spam. (not to mention
MESSAGE)=20

Sean Olson
Ericsson = Inc.

> I think using the header for both purposes is = overloading=20 it.
> The idea is
>good,=20 but a different header should be used.  Good point on =
>the spam!  That
>might = wind up=20 killing the intended functionality from getting
>implemented.
> =
>John Hearty
>Level3 =
>
>-----Original = Message-----=20
>From: Alan Johnston [mailto:alan.johnston@wcom.com]= =20
>Sent: Tuesday, October 16, 2001 4:51 PM =
>To: Henning G. Schulzrinne
>Cc: Sean=20 Olson (EUS); 'sip@ietf.org'
>Subject: Re: = [Sip]=20 Alert-Info: header
>
>
>Henning,
>
>So are you opposed to the = use of this=20 header as Sean describes
>it?   =20 The
>use
>of = the header=20 for personalized ringback without resorting to
>early media is
>a =
>good idea.
> =
>As for its use in distinctive ringing, we'll just need a = note=20
>to say that
>the=20
>use of this header requires the strongest = security and=20 trust
>relationship
>otherwise it will be the cause of the worst kind of = SPAM.=20
>
>Thanks, =
>Alan.
>
>"Henning G. Schulzrinne" wrote:
>=20
>> Alan Johnston wrote:
>> >
>> > = Sean,=20
>> >
>> = > I have=20 always assumed that the Alert-Info header being listed as a =
>> > Request header was an error - it only makes = sense for it=20
>to be used as
>>=20 > you describe - in a response (180 Ringing, to be specific,=20
>since this is
>>=20 > the only SIP response that tells the UAC to play ringback=20
>tone to the
>> >=20 caller).
>> >
>> > This then allows a UAS to deliver a = customizable ringback=20
>tone without
>> >=20 resorting to early media.
>> =
>> This is for *ring* tone, not *ringback* tone. =
>>
>> > =
>> > The use of Alert-Info in an INVITE never made = any sense=20 to
>me.  There
>> > would be a delay in the UAS from the receipt of = the=20 INVITE
>until it had
>> > fetched the alert sound.  Then, assuming = that the=20 UAS
>played the sound,
>> > how would the user even know that his SIP phone = or client=20
>was ringing?
>>=20 >
>>
>> The=20 delay would often be minuscule (a second or less), in
>particular if
>> the = Alert-Info is=20 inserted by the local proxy on the receiving side
>> (e.g., to do caller-dependent ring tones). =
>>
>> I don't = understand the last=20 question. If the URL is sound, the callee
>>=20 would hear it...
>>
>> > Used the other way around, the header does not = introduce=20 a
>delay in the
>>=20 > session setup (a delay of audible ringback while the UAC =
>fetches the
>> > = ringback sound=20 does not delay the UAS answering), and the
>caller=20 just
>> > hears a different sound = besides=20 ringing, something
>perfectly = possible=20
>> > with early media, but handled in a = much more=20 efficient way
>using this =
>> > header.
>> = >=20
>> > This is how this header will be = described in=20 bis-05, so
>let me know if I =
>> > am totally off base here.
>>
>> Yes, = unfortunately.=20
>>
>> = >=20
>> > Thanks,
>> >=20 Alan Johnston
>> > WorldCom =
>> > sip:alan@siptest.wcom.com
>> >
>> > "Sean = Olson (EUS)"=20 wrote:
>> >
>>=20 p
>>
>> --=20
>> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>>
>>=20 _______________________________________________
>> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip =
>> This list is for NEW development of the core SIP=20 Protocol
>> Use = sip-implementors@cs.columbia.edu=20 for questions on current sip
>> Use=20 sipping@ietf.org for new developments on the application of sip =
>
> =
>_______________________________________________ =
>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip =
>This list is for NEW development of the core SIP = Protocol=20
>Use sip-implementors@cs.columbia.edu for = questions on=20 current sip
>Use sipping@ietf.org for new = developments on the application of sip
>=20

------=_NextPart_000_00A9_01C1571F.9F55FD60-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 17 18:39:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08730 for ; Wed, 17 Oct 2001 18:39:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10631; Wed, 17 Oct 2001 18:05:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10538 for ; Wed, 17 Oct 2001 18:05:24 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08298 for ; Wed, 17 Oct 2001 18:05:21 -0400 (EDT) From: John.Hearty@level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA25201; Wed, 17 Oct 2001 22:05:25 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA19460; Wed, 17 Oct 2001 22:05:25 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <4GXQXHZT>; Wed, 17 Oct 2001 16:05:24 -0600 Message-ID: <17052388D394D411803900508BDFFAF601B36F87@n0214idc1.oss.level3.com> To: mnurmet@ev1.net, sean.olson@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Alert-Info: header Date: Wed, 17 Oct 2001 16:05:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15757.D1E324A0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C15757.D1E324A0 Content-Type: text/plain; charset="iso-8859-1" Henning has a point that it is unambiguous. If it is in a request it is obviously for ring played to the callee (typically out loud on a speaker), if it is in a response it is for ringback played to the caller (typically on a handset or headset). My opinion has been swayed provided it is defined in the spec. Less headers is probabally a good thing to keep SIP simple. John -----Original Message----- From: Mart Nurmet [mailto:mnurmet@ev1.net] Sent: Wednesday, October 17, 2001 2:23 PM To: Sean Olson (EUS) Cc: sip@ietf.org Subject: Re: [Sip] Alert-Info: header Sean et all: This does not seem to have that much consensus. John's point would be better served. -Mart ----- Original Message ----- From: Sean Olson (EUS) To: 'John.Hearty@Level3.com' ; alan.johnston@wcom.com ; hgs@cs.columbia.edu Cc: sip@ietf.org Sent: Wednesday, October 17, 2001 9:24 AM Subject: RE: [Sip] Alert-Info: header This is a point well taken. I wanted to generalize the header to allow for a variety of cool new features. If extending this header is not an option, could we propose a new header for this purpose? (preferably a general header). I personally don't understand the problem with using this header for "ringback" if you are allowing it for "ring tone". With regards to spam, you must be very careful in both directions. But then again, you must be very careful about accepting an INVITE as well which has a larger potential for spam. (not to mention MESSAGE) Sean Olson Ericsson Inc. > I think using the header for both purposes is overloading it. > The idea is >good, but a different header should be used. Good point on >the spam! That >might wind up killing the intended functionality from getting >implemented. > >John Hearty >Level3 > >-----Original Message----- >From: Alan Johnston [ mailto:alan.johnston@wcom.com ] >Sent: Tuesday, October 16, 2001 4:51 PM >To: Henning G. Schulzrinne >Cc: Sean Olson (EUS); 'sip@ietf.org' >Subject: Re: [Sip] Alert-Info: header > > >Henning, > >So are you opposed to the use of this header as Sean describes >it? The >use >of the header for personalized ringback without resorting to >early media is >a >good idea. > >As for its use in distinctive ringing, we'll just need a note >to say that >the >use of this header requires the strongest security and trust >relationship >otherwise it will be the cause of the worst kind of SPAM. > >Thanks, >Alan. > >"Henning G. Schulzrinne" wrote: > >> Alan Johnston wrote: >> > >> > Sean, >> > >> > I have always assumed that the Alert-Info header being listed as a >> > Request header was an error - it only makes sense for it >to be used as >> > you describe - in a response (180 Ringing, to be specific, >since this is >> > the only SIP response that tells the UAC to play ringback >tone to the >> > caller). >> > >> > This then allows a UAS to deliver a customizable ringback >tone without >> > resorting to early media. >> >> This is for *ring* tone, not *ringback* tone. >> >> > >> > The use of Alert-Info in an INVITE never made any sense to >me. There >> > would be a delay in the UAS from the receipt of the INVITE >until it had >> > fetched the alert sound. Then, assuming that the UAS >played the sound, >> > how would the user even know that his SIP phone or client >was ringing? >> > >> >> The delay would often be minuscule (a second or less), in >particular if >> the Alert-Info is inserted by the local proxy on the receiving side >> (e.g., to do caller-dependent ring tones). >> >> I don't understand the last question. If the URL is sound, the callee >> would hear it... >> >> > Used the other way around, the header does not introduce a >delay in the >> > session setup (a delay of audible ringback while the UAC >fetches the >> > ringback sound does not delay the UAS answering), and the >caller just >> > hears a different sound besides ringing, something >perfectly possible >> > with early media, but handled in a much more efficient way >using this >> > header. >> > >> > This is how this header will be described in bis-05, so >let me know if I >> > am totally off base here. >> >> Yes, unfortunately. >> >> > >> > Thanks, >> > Alan Johnston >> > WorldCom >> > sip:alan@siptest.wcom.com >> > >> > "Sean Olson (EUS)" wrote: >> > >> p >> >> -- >> Henning Schulzrinne http://www.cs.columbia.edu/~hgs >> >> _______________________________________________ >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C15757.D1E324A0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Alert-Info: header
 Henning has a point that it is unambiguous.  If it is in a request it is obviously for ring played to the callee (typically out loud on a speaker), if it is in a response it is for ringback played to the caller (typically on a handset or headset).  My opinion has been swayed provided it is defined in the spec.  Less headers is probabally a good thing to keep SIP simple.
 
John
 
-----Original Message-----
From: Mart Nurmet [mailto:mnurmet@ev1.net]
Sent: Wednesday, October 17, 2001 2:23 PM
To: Sean Olson (EUS)
Cc: sip@ietf.org
Subject: Re: [Sip] Alert-Info: header

Sean et all:
 
This does not seem to have that much consensus.  John's point would be better served.   
 
-Mart
----- Original Message -----
Sent: Wednesday, October 17, 2001 9:24 AM
Subject: RE: [Sip] Alert-Info: header

This is a point well taken. I wanted to generalize the
header to allow for a variety of cool new features. If
extending this header is not an option, could we propose
a new header for this purpose? (preferably a general header).
I personally don't understand the problem with using this
header for "ringback" if you are allowing it for "ring tone".

With regards to spam, you must be very careful in both directions.
But then again, you must be very careful about accepting an INVITE
as well which has a larger potential for spam. (not to mention
MESSAGE)

Sean Olson
Ericsson Inc.

> I think using the header for both purposes is overloading it.
> The idea is
>good, but a different header should be used.  Good point on
>the spam!  That
>might wind up killing the intended functionality from getting
>implemented.
>
>John Hearty
>Level3
>
>-----Original Message-----
>From: Alan Johnston [mailto:alan.johnston@wcom.com]
>Sent: Tuesday, October 16, 2001 4:51 PM
>To: Henning G. Schulzrinne
>Cc: Sean Olson (EUS); 'sip@ietf.org'
>Subject: Re: [Sip] Alert-Info: header
>
>
>Henning,
>
>So are you opposed to the use of this header as Sean describes
>it?    The
>use
>of the header for personalized ringback without resorting to
>early media is
>a
>good idea.
>
>As for its use in distinctive ringing, we'll just need a note
>to say that
>the
>use of this header requires the strongest security and trust
>relationship
>otherwise it will be the cause of the worst kind of SPAM.
>
>Thanks,
>Alan.
>
>"Henning G. Schulzrinne" wrote:
>
>> Alan Johnston wrote:
>> >
>> > Sean,
>> >
>> > I have always assumed that the Alert-Info header being listed as a
>> > Request header was an error - it only makes sense for it
>to be used as
>> > you describe - in a response (180 Ringing, to be specific,
>since this is
>> > the only SIP response that tells the UAC to play ringback
>tone to the
>> > caller).
>> >
>> > This then allows a UAS to deliver a customizable ringback
>tone without
>> > resorting to early media.
>>
>> This is for *ring* tone, not *ringback* tone.
>>
>> >
>> > The use of Alert-Info in an INVITE never made any sense to
>me.  There
>> > would be a delay in the UAS from the receipt of the INVITE
>until it had
>> > fetched the alert sound.  Then, assuming that the UAS
>played the sound,
>> > how would the user even know that his SIP phone or client
>was ringing?
>> >
>>
>> The delay would often be minuscule (a second or less), in
>particular if
>> the Alert-Info is inserted by the local proxy on the receiving side
>> (e.g., to do caller-dependent ring tones).
>>
>> I don't understand the last question. If the URL is sound, the callee
>> would hear it...
>>
>> > Used the other way around, the header does not introduce a
>delay in the
>> > session setup (a delay of audible ringback while the UAC
>fetches the
>> > ringback sound does not delay the UAS answering), and the
>caller just
>> > hears a different sound besides ringing, something
>perfectly possible
>> > with early media, but handled in a much more efficient way
>using this
>> > header.
>> >
>> > This is how this header will be described in bis-05, so
>let me know if I
>> > am totally off base here.
>>
>> Yes, unfortunately.
>>
>> >
>> > Thanks,
>> > Alan Johnston
>> > WorldCom
>> > sip:alan@siptest.wcom.com
>> >
>> > "Sean Olson (EUS)" wrote:
>> >
>> p
>>
>> --
>> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>>
>> _______________________________________________
>> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>

------_=_NextPart_001_01C15757.D1E324A0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 18 10:49:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11696 for ; Thu, 18 Oct 2001 10:49:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09640; Thu, 18 Oct 2001 10:13:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09609 for ; Thu, 18 Oct 2001 10:13:14 -0400 (EDT) Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10769 for ; Thu, 18 Oct 2001 10:13:10 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix1-2.free.fr (Postfix) with ESMTP id 5A20BAB241 for ; Thu, 18 Oct 2001 16:13:14 +0200 (CEST) Received: from imp2-2.free.fr (www-data@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f9IEDEpl015318 for ; Thu, 18 Oct 2001 16:13:14 +0200 Received: (from www-data@localhost) by imp2-2.free.fr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id f9IEDDgA015314 for sip@ietf.org; Thu, 18 Oct 2001 16:13:13 +0200 To: sip@ietf.org Message-ID: <1003414393.3bcee379bd28e@imp.free.fr> Date: Thu, 18 Oct 2001 16:13:13 +0200 (MEST) From: patrick.mourot@online.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 212.208.74.5 Content-Transfer-Encoding: 8bit Subject: [Sip] Diversion status ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Sirs, I was asked to put this question in SIP mailing list. The following I-D "draft-levy-sip-diversion-02.txt" is soon out of date. Could someone give us some pointers about diversion when using voice mail ? Is diversion header under definition over there ? How can we carry the diversion cause to the voice mail machine? TIA for your response, Patrick _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 18 13:03:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15375 for ; Thu, 18 Oct 2001 13:03:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14162; Thu, 18 Oct 2001 12:40:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14131 for ; Thu, 18 Oct 2001 12:40:28 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([212.143.185.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14722 for ; Thu, 18 Oct 2001 12:40:24 -0400 (EDT) Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id <4115FT1L>; Thu, 18 Oct 2001 18:39:55 +0200 Message-ID: From: Itamar Gilad To: "'SIP list'" Date: Thu, 18 Oct 2001 18:39:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] Possible interop issues due to BNF of digest auth Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org SIP borrows the definitions of authentication headers from RFC 2616 and RFC 2617 RFC 2616 14.47: WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge RFC 2616 14.33: Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge From RFC 2617 3.2.1 as follows: challenge = "Digest" digest-challenge digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] ) This means that there's a great deal of freedom in the way WWW-Authenticate and Proxy-Authenticate headers are constructed which may lead to major interop issues. We've seen some of this in the last SipIt. For example the header below is valid: WWW-Authenticate: Digest realm="realm1", realm="realm2", nonce="aaaaaEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", nonce="rrrrrEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", opaque="bbbbbbFiYTAwMzgzYTY4MA==", stale=false, algorithm=md5, algorithm=sha1, qop="auth, auth-int", Digest realm="realm3", realm="realm4", nonce="aaaaaEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", opaque="ttttttFiYTAwMzgzYTY4MA==", stale=false, algorithm=sha1, qop="auth, auth-int" Questions: 1. Do you have a parser that can parse this header? 2. Can you explain the semantics of this header? 3. Shouldn't we restrict the way SIP messages use this syntax to a more "canonic" form? 4. If the answer to (3) is no: should we add this as a torture message? Itamar Gilad RADVISION itamarg@radvision.com 24 Raul Wallenberg St. tel: +972 3 7659938 Building D mob: +972 56 429938 Tel-Aviv 69719 fax: +972 3 6472637 Israel _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 18 14:31:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17679 for ; Thu, 18 Oct 2001 14:31:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16836; Thu, 18 Oct 2001 14:04:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16805 for ; Thu, 18 Oct 2001 14:04:53 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17027 for ; Thu, 18 Oct 2001 14:04:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9II308P027340; Thu, 18 Oct 2001 14:03:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQ34Q>; Thu, 18 Oct 2001 14:04:10 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E6C6@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'aki.niemi@nokia.com'" , brett@broadsoft.com, ajaych@windows.microsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Thu, 18 Oct 2001 14:04:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > The realm can be used if the proxy is > > certain that it is unique to the proxy. > > Otherwise, the nonce can be generated/parsed > > in a way that uniquely identifies the > > appropriate proxy. > > The realm only works for Digest authentication. I suppose at > least in Basic > authentication, the proxy could just pick the topmost > Proxy-Authorization > and process that. Topmost isn't good enough. You'll have to look at all of them and see if one matches you. You could generate a false positive in this case and there's nothing in Basic that's going to get you past that. You can avoid the problem quite cleanly by never issuing a Basic challenge (do you _really_ want to share your secret with everyone in-between you and the endpoint?). RjS _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 18 17:01:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19744 for ; Thu, 18 Oct 2001 17:01:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22893; Thu, 18 Oct 2001 16:32:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22863 for ; Thu, 18 Oct 2001 16:32:27 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19363 for ; Thu, 18 Oct 2001 16:32:20 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Oct 2001 12:52:15 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 18 Oct 2001 12:52:14 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Oct 2001 12:52:14 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Oct 2001 12:52:13 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Thu, 18 Oct 2001 12:51:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Thu, 18 Oct 2001 12:51:41 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC121BA1E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [Sip] 407s from different proxies on a SIP session Thread-Index: AcFX/3Y9kXVflAdrSbOasEprKcU4+gADgelA From: "Ajay Chitturi" To: "Robert Sparks" , , Cc: X-OriginalArrivalTime: 18 Oct 2001 19:51:43.0340 (UTC) FILETIME=[4FB912C0:01C1580E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA22864 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Using the realm / nonce to identify the auth header could be hacky.. The challenging proxies could use the same realm and I'm not sure if the nonces generated by different machines can be required to be unique. -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Thursday, October 18, 2001 11:04 AM To: 'aki.niemi@nokia.com'; brett@broadsoft.com; Ajay Chitturi Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session > > The realm can be used if the proxy is > > certain that it is unique to the proxy. > > Otherwise, the nonce can be generated/parsed > > in a way that uniquely identifies the > > appropriate proxy. > > The realm only works for Digest authentication. I suppose at > least in Basic > authentication, the proxy could just pick the topmost > Proxy-Authorization > and process that. Topmost isn't good enough. You'll have to look at all of them and see if one matches you. You could generate a false positive in this case and there's nothing in Basic that's going to get you past that. You can avoid the problem quite cleanly by never issuing a Basic challenge (do you _really_ want to share your secret with everyone in-between you and the endpoint?). RjS _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 18 19:52:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21530 for ; Thu, 18 Oct 2001 19:52:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27574; Thu, 18 Oct 2001 19:28:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27543 for ; Thu, 18 Oct 2001 19:28:29 -0400 (EDT) Received: from mail1.telefonica.com.ar ([168.226.49.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21337 for ; Thu, 18 Oct 2001 19:28:24 -0400 (EDT) Received: by MAIL1 with Internet Mail Service (5.5.2653.19) id <4XLF6GPZ>; Thu, 18 Oct 2001 20:15:28 -0300 Message-ID: <19364262E259D51198BA0008C7E6528E091AFA@MSTELEFONICA8> From: De Leo Walter To: "'sip@ietf.org'" Date: Thu, 18 Oct 2001 19:14:30 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] Basic questions. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Excuse me I am new in this of SIP and have some basic questions whose answers I couldnt find in the list digest. If this questions bother you, or you think it is not the propper list to post them, please let me know, and tell me where should I post them. Here the questions: 1) In SIPbis (04) the use of tags is mandatory for From headers, it was not the case of RFC 2543, what is it required for?. (Call legs can be distinguished by means of To tags (all other headers being equal). It would have sense if URLs are removed (it was a Mr Rosemberg Proposal)from Call leg identification but it is not the case yet, is it?) 2) More basic, what is the minimum length of a tag? 3) I have seen in one of the examples in the draft (the 20.5 forking example) that a 200 response to a CANCEL didn't have a To tag. But the 487 response to the INVITE being cancelled did include a To tag. Why is that. I understand that the response to the CANCEL doesn't have a To Tag because the call leg does not exist as the callee was not located. But why there is a To Tag in the 487, is a short lifed call-leg created between caller and proxy? 4) Please don't laugh at me but I couldn't find out what is being referenced when the draft sends you to [Hx.x]:( Well, forgive me for the extension of the message and thank you in advance. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Oct 18 19:58:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21594 for ; Thu, 18 Oct 2001 19:58:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28010; Thu, 18 Oct 2001 19:43:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27981 for ; Thu, 18 Oct 2001 19:43:20 -0400 (EDT) Received: from mail1.telefonica.com.ar ([168.226.49.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21473 for ; Thu, 18 Oct 2001 19:43:15 -0400 (EDT) Received: by MAIL1 with Internet Mail Service (5.5.2653.19) id <4XLF6HTT>; Thu, 18 Oct 2001 20:27:42 -0300 Message-ID: <19364262E259D51198BA0008C7E6528E091AFB@MSTELEFONICA8> From: De Leo Walter To: "'sip@ietf.org'" Date: Thu, 18 Oct 2001 20:24:50 -0300 Expiry-Date: Sat, 20 Oct 2001 20:25:38 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] Recuperar: Basic questions. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org De Leo Walter desea recuperar el mensaje "Basic questions.". _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 19 03:55:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12192 for ; Fri, 19 Oct 2001 03:55:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15113; Fri, 19 Oct 2001 03:24:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15085 for ; Fri, 19 Oct 2001 03:24:16 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11256 for ; Fri, 19 Oct 2001 03:24:13 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9J7Ojf20636 for ; Fri, 19 Oct 2001 10:24:45 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Oct 2001 10:24:09 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VHW5C>; Fri, 19 Oct 2001 10:24:09 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC36@esebe013.NOE.Nokia.com> To: rsparks@dynamicsoft.com, brett@broadsoft.com, ajaych@windows.microsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Fri, 19 Oct 2001 10:24:07 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, > Topmost isn't good enough. You'll have to look at all of them > and see if one matches you. I agree, but I seem to remember a thread on this on one of the lists some time ago, and using the topmost header seems to be the way at least some people are doing it. > You can avoid the problem quite cleanly by never issuing > a Basic challenge (do you _really_ want to share your > secret with everyone in-between you and the endpoint?). No no! I'm not suggesting Basic should ever be used. But maybe there is a need to clarify this issue in the bis security section rather than rely on servers issuing unique nonces and realms? Also going through all of the credentials seems a bit too much work for a lazy proxy ;-) Cheers, Aki _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 19 09:56:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19215 for ; Fri, 19 Oct 2001 09:56:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25265; Fri, 19 Oct 2001 09:38:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25236 for ; Fri, 19 Oct 2001 09:38:51 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18718 for ; Fri, 19 Oct 2001 09:38:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9JDb18P002145; Fri, 19 Oct 2001 09:37:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQQ6G>; Fri, 19 Oct 2001 09:38:12 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E6CA@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'aki.niemi@nokia.com'" , Robert Sparks , brett@broadsoft.com, ajaych@windows.microsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Fri, 19 Oct 2001 09:38:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org When a forking proxy returns a 407, it has to combine the challenges from _all_ of the 407's it received for the request into that one response. This allows the endpoint to provide credentials for everything in the path of the next request (instead of just one arbitrary branch). Thus, only looking at the topmost header will not work. RjS > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Friday, October 19, 2001 2:24 AM > To: rsparks@dynamicsoft.com; brett@broadsoft.com; > ajaych@windows.microsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] 407s from different proxies on a SIP session > > > Hi, > > > Topmost isn't good enough. You'll have to look at all of them > > and see if one matches you. > > I agree, but I seem to remember a thread on this on one of > the lists some > time ago, and using the topmost header seems to be the way at > least some > people are doing it. > > > You can avoid the problem quite cleanly by never issuing > > a Basic challenge (do you _really_ want to share your > > secret with everyone in-between you and the endpoint?). > > No no! I'm not suggesting Basic should ever be used. > > But maybe there is a need to clarify this issue in the bis > security section > rather than rely on servers issuing unique nonces and realms? > Also going > through all of the credentials seems a bit too much work for > a lazy proxy > ;-) > > Cheers, > Aki > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 19 09:57:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19238 for ; Fri, 19 Oct 2001 09:57:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25029; Fri, 19 Oct 2001 09:30:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24982 for ; Fri, 19 Oct 2001 09:30:33 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18398 for ; Fri, 19 Oct 2001 09:30:30 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9JDSg8P002085; Fri, 19 Oct 2001 09:28:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQQ52>; Fri, 19 Oct 2001 09:29:52 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E6C9@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Ajay Chitturi'" , Robert Sparks , aki.niemi@nokia.com, brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Fri, 19 Oct 2001 09:29:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Realm is defined in the DIGEST drafts to uniquely identify a security domain. If more than one proxy uses the same realm, they better accept the same credentials. A good nonce is going to be globally unique (using the "extremely low probability of collision" definition of uniqueness). RjS > -----Original Message----- > From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] > Sent: Thursday, October 18, 2001 2:52 PM > To: Robert Sparks; aki.niemi@nokia.com; brett@broadsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] 407s from different proxies on a SIP session > > > Using the realm / nonce to identify the auth header could be > hacky.. The challenging proxies could use the same realm and > I'm not sure if the nonces generated by different machines > can be required to be unique. > > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Thursday, October 18, 2001 11:04 AM > To: 'aki.niemi@nokia.com'; brett@broadsoft.com; Ajay Chitturi > Cc: sip@ietf.org > Subject: RE: [Sip] 407s from different proxies on a SIP session > > > > > The realm can be used if the proxy is > > > certain that it is unique to the proxy. > > > Otherwise, the nonce can be generated/parsed > > > in a way that uniquely identifies the > > > appropriate proxy. > > > > The realm only works for Digest authentication. I suppose at > > least in Basic > > authentication, the proxy could just pick the topmost > > Proxy-Authorization > > and process that. > > Topmost isn't good enough. You'll have to look at all of them > and see if one matches you. > > You could generate a false positive in this case and there's > nothing in Basic that's going to get you past that. > > You can avoid the problem quite cleanly by never issuing > a Basic challenge (do you _really_ want to share your > secret with everyone in-between you and the endpoint?). > > RjS > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 19 10:22:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19988 for ; Fri, 19 Oct 2001 10:22:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25791; Fri, 19 Oct 2001 09:58:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25760 for ; Fri, 19 Oct 2001 09:58:28 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19265 for ; Fri, 19 Oct 2001 09:58:24 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9JDx2f25587 for ; Fri, 19 Oct 2001 16:59:02 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Oct 2001 16:58:26 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6V2MQP>; Fri, 19 Oct 2001 16:58:16 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC3D@esebe013.NOE.Nokia.com> To: rsparks@dynamicsoft.com, ajaych@windows.microsoft.com, brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Fri, 19 Oct 2001 16:58:14 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Realm is defined in the DIGEST drafts to uniquely > identify a security domain. If more than one proxy > uses the same realm, they better accept the same > credentials. Which draft is this? Referring to RFC 2617, the client can determine a protection space by looking at the realm together with the Request-URI, but the realm alone is not unique. > A good nonce is going to be globally unique (using > the "extremely low probability of collision" definition > of uniqueness). I agree, if a nonce is carefully picked, there is little chance of collision. Cheers, Aki > > RjS > > > -----Original Message----- > > From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] > > Sent: Thursday, October 18, 2001 2:52 PM > > To: Robert Sparks; aki.niemi@nokia.com; brett@broadsoft.com > > Cc: sip@ietf.org > > Subject: RE: [Sip] 407s from different proxies on a SIP session > > > > > > Using the realm / nonce to identify the auth header could be > > hacky.. The challenging proxies could use the same realm and > > I'm not sure if the nonces generated by different machines > > can be required to be unique. > > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Thursday, October 18, 2001 11:04 AM > > To: 'aki.niemi@nokia.com'; brett@broadsoft.com; Ajay Chitturi > > Cc: sip@ietf.org > > Subject: RE: [Sip] 407s from different proxies on a SIP session > > > > > > > > The realm can be used if the proxy is > > > > certain that it is unique to the proxy. > > > > Otherwise, the nonce can be generated/parsed > > > > in a way that uniquely identifies the > > > > appropriate proxy. > > > > > > The realm only works for Digest authentication. I suppose at > > > least in Basic > > > authentication, the proxy could just pick the topmost > > > Proxy-Authorization > > > and process that. > > > > Topmost isn't good enough. You'll have to look at all of them > > and see if one matches you. > > > > You could generate a false positive in this case and there's > > nothing in Basic that's going to get you past that. > > > > You can avoid the problem quite cleanly by never issuing > > a Basic challenge (do you _really_ want to share your > > secret with everyone in-between you and the endpoint?). > > > > RjS > > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 19 12:53:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24196 for ; Fri, 19 Oct 2001 12:52:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00676; Fri, 19 Oct 2001 12:21:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00644 for ; Fri, 19 Oct 2001 12:20:57 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22751 for ; Fri, 19 Oct 2001 12:20:53 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f9JGQoD14144 for ; Fri, 19 Oct 2001 11:26:50 -0500 Message-ID: <00bf01c158ba$03bc7bd0$7d7075d5@flak> From: "Dean Willis" To: Date: Fri, 19 Oct 2001 11:20:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Volunteer needed for script to post SIP open issues from Bugzilla Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan has been using a bugzilla server to to track open issues with SIP. It seems that the general public has an interest in knowing what those issues are, and what the status might be. It has been proposed that: "we write a script for dean's site that logs into bugzilla, runs a query for all open issues, requests the long format, and then takes the resulting html doc, scrapes it clean of urls and other useless gunk, and displays it. This gives people access to bugzilla in the sense that they can see the bugs, but they can't access it directly, add comments, etc." As Tonto is reputed to have said "what do you mean 'we', paleface?" (see "The Lone Ranger" television series for context). So, any of you bright-eyed code wranglers feel like taking this on? I'd suggest something like a perl script that can be run daily from cron, which outputs a copy of the needed info in HTML. I suspect my server's not up to doing it live as a CGI. -- Dean _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 19 14:15:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26648 for ; Fri, 19 Oct 2001 14:15:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02307; Fri, 19 Oct 2001 13:25:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02278 for ; Fri, 19 Oct 2001 13:25:54 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25174 for ; Fri, 19 Oct 2001 13:25:50 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9JHO58P004636; Fri, 19 Oct 2001 13:24:05 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQSBY>; Fri, 19 Oct 2001 13:25:16 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E6CF@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] Volunteer needed for script to post SIP open issues fro m Bugzilla Date: Fri, 19 Oct 2001 13:25:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm willing to do this. RjS > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, October 19, 2001 11:21 AM > To: sip@ietf.org > Subject: [Sip] Volunteer needed for script to post SIP open > issues from > Bugzilla > > > Jonathan has been using a bugzilla server to to track open > issues with SIP. > > It seems that the general public has an interest in knowing what those > issues are, and what the status might be. > > It has been proposed that: > > "we write a script for dean's site that logs into bugzilla, > runs a query for > all open issues, requests the long format, and then takes the > resulting html > doc, scrapes it clean of urls and other useless gunk, and > displays it. This > gives people access to bugzilla in the sense that they can > see the bugs, but > they can't access it directly, add comments, etc." > > As Tonto is reputed to have said "what do you mean 'we', > paleface?" (see > "The Lone Ranger" television series for context). > > So, any of you bright-eyed code wranglers feel like taking this on? > > I'd suggest something like a perl script that can be run > daily from cron, > which outputs a copy of the needed info in HTML. I suspect my > server's not > up to doing it live as a CGI. > > -- > Dean > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Oct 19 15:10:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28241 for ; Fri, 19 Oct 2001 15:10:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04911; Fri, 19 Oct 2001 14:42:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04880 for ; Fri, 19 Oct 2001 14:42:44 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27636 for ; Fri, 19 Oct 2001 14:42:35 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9JIg4j03534 for ; Fri, 19 Oct 2001 20:42:04 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9JIg3B27136 for ; Fri, 19 Oct 2001 21:42:03 +0300 (EET DST) Message-ID: <3BD073FD.7CD06D6C@lmf.ericsson.se> Date: Fri, 19 Oct 2001 21:42:05 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Questions on the SIP privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a couple of questions/issues on the SIP privacy draft (draft-ietf-sip-privace-02.txt) First, chapter 6.1 says that the pri-screen parameter SHOULD NOT be included in the initial INVITE when created by the UAC. That is very clear for a SIP phone. But, a PSTN GW, doing ISUP-SIP mapping, COULD use information received from ISUP to set this parameter. Since multiple instances of the parameter may be added by proxies, they could still do whatever verification they wish. Second, chapter 6.1 also says: >* From: The UAC SHOULD supply a cryptographically random > identifier for the userinfo, and a non-identifying hostname, e.g. > "localhost", in the host name. My question is: why does the UAC have to put a userinfo value in the From header at all, since it's optional? I DO understand it may be needed in the Contact header, but why in the From? Also, if the Remote-Party-ID is used, why does the UAC have to set the display-name to "anonymous" etc? I know it's the way it's done in bis, but is it really needed if the Remote-Party-ID header is used? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Oct 21 18:20:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17812 for ; Sun, 21 Oct 2001 18:20:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20168; Sun, 21 Oct 2001 17:50:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20137 for ; Sun, 21 Oct 2001 17:50:44 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17720 for ; Sun, 21 Oct 2001 17:50:43 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9LLmk8P011612; Sun, 21 Oct 2001 17:48:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQ45Z>; Sun, 21 Oct 2001 17:49:57 -0400 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'Ajay Chitturi'" , aki.niemi@nokia.com, brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Sun, 21 Oct 2001 17:49:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Friday, October 19, 2001 9:30 AM > To: 'Ajay Chitturi'; Robert Sparks; aki.niemi@nokia.com; > brett@broadsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] 407s from different proxies on a SIP session > > > Realm is defined in the DIGEST drafts to uniquely > identify a security domain. If more than one proxy > uses the same realm, they better accept the same > credentials. The username and password probably will be the same, but I suspect each proxy would generally choose separate nonces, so that two digest responses in two different Proxy-Authorization headers for the same realm would not be equally usable to both. > > A good nonce is going to be globally unique (using > the "extremely low probability of collision" definition > of uniqueness). I really think realm is the right thing, and we should specify one, and only one way to determine which credentials are "your own" for a proxy. I would rather mandate that realms be globally unique, probably using something like "com.dynamicsoft.serviceA" or some other such kind of hierarchy, as needed. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Oct 21 18:31:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17879 for ; Sun, 21 Oct 2001 18:31:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20245; Sun, 21 Oct 2001 17:59:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20220 for ; Sun, 21 Oct 2001 17:59:19 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17733 for ; Sun, 21 Oct 2001 17:59:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9LLvZ8P011635; Sun, 21 Oct 2001 17:57:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQ46B>; Sun, 21 Oct 2001 17:58:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'Itamar Gilad'" , "'SIP list'" Subject: RE: [Sip] Possible interop issues due to BNF of digest auth Date: Sun, 21 Oct 2001 17:58:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Itamar Gilad [mailto:ItamarG@radvision.com] > Sent: Thursday, October 18, 2001 12:40 PM > To: 'SIP list' > Subject: [Sip] Possible interop issues due to BNF of digest auth > > > SIP borrows the definitions of authentication headers from > RFC 2616 and RFC > 2617 > > RFC 2616 14.47: > WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge > > RFC 2616 14.33: > Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge > > From RFC 2617 3.2.1 as follows: > > challenge = "Digest" digest-challenge > > digest-challenge = 1#( realm | [ domain ] | nonce | > [ opaque ] |[ stale ] | [ algorithm ] | > [ qop-options ] | [auth-param] ) > > This means that there's a great deal of freedom in the way > WWW-Authenticate > and Proxy-Authenticate headers are constructed which may lead to major > interop issues. We've seen some of this in the last SipIt. > For example the > header below is valid: > > WWW-Authenticate: Digest realm="realm1", realm="realm2", > nonce="aaaaaEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", > nonce="rrrrrEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", > opaque="bbbbbbFiYTAwMzgzYTY4MA==", stale=false, > algorithm=md5, algorithm=sha1, qop="auth, auth-int", > Digest realm="realm3", realm="realm4", > nonce="aaaaaEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", > opaque="ttttttFiYTAwMzgzYTY4MA==", stale=false, > algorithm=sha1, qop="auth, > auth-int" No, this is not valid. It passes the grammar, but grammars are ill suited at expressing more complex constraints. In this case, the grammar does not specify that duplicates of certain parameters are not allowed. However, I think it is reasonably clear from the specifications that you can only have one realm, one nonce, and so on. Most web browsers have gotten this right, I think SIP implementors can too. As an example of this, consider the Date header. Dates introduce constraints that are far too complex to place in the grammar (for example, Feburary 29 is allowed in some years), and it is unrealistic to even try. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Oct 21 18:46:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17944 for ; Sun, 21 Oct 2001 18:46:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20848; Sun, 21 Oct 2001 18:24:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20820 for ; Sun, 21 Oct 2001 18:24:15 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17827 for ; Sun, 21 Oct 2001 18:24:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9LMMY8P011699; Sun, 21 Oct 2001 18:22:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQ465>; Sun, 21 Oct 2001 18:23:44 -0400 Message-ID: From: Jonathan Rosenberg To: Sean Olson , "'Alan Johnston'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Alert-Info: header Date: Sun, 21 Oct 2001 18:23:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Tuesday, October 16, 2001 3:24 PM To: 'Alan Johnston' Cc: 'sip@ietf.org' Subject: RE: [Sip] Alert-Info: header >Sean, > >>This then allows a UAS to deliver a customizable ringback tone without >>resorting to early media. > >Yes, this is the primary feature I am looking for. However, it is >not the only feature I would like to support with this header. >For this reason, I think Alert-Info should remain a general header. >I will elaborate further below. > >>The use of Alert-Info in an INVITE never made any sense to me. There >>would be a delay in the UAS from the receipt of the INVITE until it had >>fetched the alert sound. Then, assuming that the UAS played the sound, >>how would the user even know that his SIP phone or client was ringing? > >This is fairly confusing if you assume that the Alert-Info: can >only apply to ring(back) tone. If you broaden the header to mean >"this is information to be rendered to the end user during the >alerting period", then things start to make more sense. For example, >if I send an http: URL in the Alert-Info: header in the INVITE, this >could point to a thumbnail icon which provides an enhanced caller ID >feature. I think this is what Call-Info was meant to do. In fact, an "icon" parameter has already been defined for this purpose exactly. I, for one, had also thought that Alert-Info was meant as a response header. I don't see much use in the request for ringtone, since I would expect that ringtone is primarily going to be something the called party selects, not the caller. Whether its a new header, or a different header, the ability for the caller to specify content that the callee should render, play, or whatever, is at the same time both a powerful feature and a very dangerous one. I think its important that the specification more clearly discuss the security issues here, and recommend that these headers only be followed for calls that can be authenticated. That doesn't mean that the called party needs to authenticate the caller; one can imagine a system in a call center where the called party is an agent, and the agent system inserts these headers after identifying the caller through some means (IVR, or whatever). So, as long as the call comes from the agent system, the agent is safe in rendering these headers. Furthermore, there is a tradeoff in how general you make this header. The reason we made Alert-Info and Call-Info separate things is that we want the headers to be as precise as possible about what the purpose of the content is. This ensures that the UA can treat it in an appropriate fashion for its UI, and it also helps the UA perform appropriate filtering. For example, if a UA gets a request with a Call-Info that contains an http URL with an "icon" param, but the fetched content is an executable or VBscript, its a safe bet its to be discarded. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Oct 21 19:01:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18024 for ; Sun, 21 Oct 2001 19:01:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21342; Sun, 21 Oct 2001 18:42:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21314 for ; Sun, 21 Oct 2001 18:42:49 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17924 for ; Sun, 21 Oct 2001 18:42:47 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9LMf18P011736; Sun, 21 Oct 2001 18:41:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQ47J>; Sun, 21 Oct 2001 18:42:12 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sarvi Shanmugham'" , eburger@snowshore.com Cc: sip@ietf.org Subject: RE: [Sip] SIP INFO method - Any reason it MUST BE stateless. Date: Sun, 21 Oct 2001 18:42:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > Sent: Tuesday, October 16, 2001 2:13 AM > To: eburger@snowshore.com > Cc: sip@ietf.org > Subject: Re: [Sip] SIP INFO method - Any reason it MUST BE stateless. > > > Hi Eric, > This is not to carry signalling information. The scenario > that we are > looking at is to setup a SIP session to a media server with a > 2-way RTP stream > to it. > SIP is used for setting up this session. > The INFO method would be used to carry > commands/information/responses > between the applications sitting at either end of the SIP session. INFO is not meant as a universal way to carry stuff between elements. What you are proposing, IMHO, is to use SIP as a tunneling method for MGCP or RTSP or something similar. I see exactly zero value in doing things like that. They are recipes for interoperability failures of astounding proportions, and are contrary to the design guidelines we have established for sip: http://search.ietf.org/internet-drafts/draft-ietf-sip-guidelines-02.txt If you are worried about transporting such large content with sip and its responses, this should be interpreted as a clear sign that SIP is the *WRONG THING*. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Oct 21 19:06:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18087 for ; Sun, 21 Oct 2001 19:06:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21489; Sun, 21 Oct 2001 18:49:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21458 for ; Sun, 21 Oct 2001 18:49:42 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17972 for ; Sun, 21 Oct 2001 18:49:40 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9LMlV8P011751; Sun, 21 Oct 2001 18:47:31 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQ473>; Sun, 21 Oct 2001 18:48:42 -0400 Message-ID: From: Jonathan Rosenberg To: Jonathan Rosenberg , "'sip@ietf.org'" Cc: "'sip-implementors@cs.columbia.edu'" Subject: RE: [Sip] DEPRECATION WARNING: () comments in Via grammar Date: Sun, 21 Oct 2001 18:48:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org As there was no response to this within a two week interval, you can consider the use of comments in Via deprecated. Their usage in other headers is a separate question. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, October 09, 2001 11:55 AM > To: 'sip@ietf.org' > Cc: 'sip-implementors@cs.columbia.edu' > Subject: [Sip] DEPRECATION WARNING: () comments in Via grammar > > > Folks, > > The bis editor team is considering the removal of the use of > comments in the > Via header. The comment is a paren enclosed text: > > Via: SIP/2.0/UDP 1.2.3.4 (this is a comment) > > Before its deprecated, we need to know if anyone is SENDING > them (it doesn't > matter if your parser can receive them). Please send a note > to the authors > or the list if you are still sending packets with Via comments. > > Thanks, > Jonathan R. > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Oct 21 19:07:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18098 for ; Sun, 21 Oct 2001 19:07:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21433; Sun, 21 Oct 2001 18:48:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21402 for ; Sun, 21 Oct 2001 18:48:12 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17968 for ; Sun, 21 Oct 2001 18:48:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9LMkU8P011747; Sun, 21 Oct 2001 18:46:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQ47N>; Sun, 21 Oct 2001 18:47:41 -0400 Message-ID: From: Jonathan Rosenberg To: "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Subject: RE: [Sip] privacy draft - use of Remote-party-ID header in method s other th an INVITE Date: Sun, 21 Oct 2001 18:47:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The fact that it is only allowed in INVITE is a surprise to me... THe presence spec already mentions its usage in SUBSCRIBE, to provide exactly the same kind of features it provides in INVITE. I see no particular reason that the extension should be limited to INVITE. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, October 10, 2001 9:24 AM > To: 'sip@ietf.org' > Subject: [Sip] privacy draft - use of Remote-party-ID header > in methods > other th an INVITE > > > Currently the privacy draft defines the Remote-Party-ID > header only for use > in the INVITE method. > > For some other methods, e.g. REGISTER and REFER, it would > appear useful to > be able to pass other identifiers of the user (in addition to > the From and > Contact header) between SIP applications. These identifiers > are probably > much the same as those already covered in the Remote-Party-ID header. > > What issues would people see in extending the use of the > Remote-Party-ID > header to a defined set of other methods? > > Would this be done by extending the privacy draft, or by a > new extension > altogether, or by some completely new reorganisation of the > documentation > altogether? > > > Keith > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 00:15:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22594 for ; Mon, 22 Oct 2001 00:15:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29795; Sun, 21 Oct 2001 23:51:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29763 for ; Sun, 21 Oct 2001 23:51:37 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22488 for ; Sun, 21 Oct 2001 23:51:35 -0400 (EDT) Received: from jku.iptel.org ([63.113.46.91]) by fox.iptel.org (8.11.6/8.11.2) with ESMTP id f9M3olI05717; Mon, 22 Oct 2001 05:50:47 +0200 Message-Id: <5.1.0.14.0.20011022010727.02889290@mailhub.fokus.gmd.de> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Oct 2001 01:17:20 +0200 To: Jonathan Rosenberg , Robert Sparks , "'Ajay Chitturi'" , aki.niemi@nokia.com, brett@broadsoft.com From: Jiri Kuthan Subject: RE: [Sip] 407s from different proxies on a SIP session Cc: sip@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org If a stateless proxy is entirely stateless and does not remember challenges, taking realm would work and taking realm+challenge would not. Why should an authentication server keep no challenge? Perhaps to avoid synchronization overhead in a server farm where a re-sent request may hit a different server than the original server did. Which is, IMHO, doable with the same security level as servers that keep challenges longer than for one-way use. -Jiri At 11:49 PM 10/21/2001, Jonathan Rosenberg wrote: >I really think realm is the right thing, and we should specify one, and only >one way to determine which credentials are "your own" for a proxy. I would >rather mandate that realms be globally unique, probably using something like >"com.dynamicsoft.serviceA" or some other such kind of hierarchy, as needed. > >-Jonathan R. -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 00:16:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22605 for ; Mon, 22 Oct 2001 00:16:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29065; Sun, 21 Oct 2001 23:08:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29034 for ; Sun, 21 Oct 2001 23:08:56 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21827 for ; Sun, 21 Oct 2001 23:08:56 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA17302; Sun, 21 Oct 2001 23:08:58 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id f9M38vO01822; Sun, 21 Oct 2001 23:08:57 -0400 (EDT) Message-ID: <3BD38E2D.716DAEE8@cs.columbia.edu> Date: Sun, 21 Oct 2001 23:10:37 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Sean Olson , "'Alan Johnston'" , "'sip@ietf.org'" Subject: Re: [Sip] Alert-Info: header References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I, for one, had also thought that Alert-Info was meant as a response header. > I don't see much use in the request for ringtone, since I would expect that > ringtone is primarily going to be something the called party selects, not > the caller. This is at variance with the discussion that I remember when we first discussed this, where this came up in the context of distinctive ringing. Yes, the called party should select the ring tone, but the idea is that the callee's proxy inserts this header, based on some database lookup, script or what have you. This seems like a pretty good implementation to me, as it avoids end systems having to deal with maintaining a callee mapping table, while still allowing the end system flexibility in whether to observe the header or not. The callee's proxy server can then also override any choices made by the caller, or if sufficiently trusted, use that choice. This seems like the right separation of policy from mechanism, i.e., any number of policies can be supported, without encoding them into headers. Proxy-signed headers are clearly helpful here. > > Whether its a new header, or a different header, the ability for the caller > to specify content that the callee should render, play, or whatever, is at > the same time both a powerful feature and a very dangerous one. I think its > important that the specification more clearly discuss the security issues > here, and recommend that these headers only be followed for calls that can > be authenticated. That doesn't mean that the called party needs to > authenticate the caller; one can imagine a system in a call center where the > called party is an agent, and the agent system inserts these headers after > identifying the caller through some means (IVR, or whatever). So, as long as > the call comes from the agent system, the agent is safe in rendering these > headers. Or a proxy, for that matter. (I can't tell if you mean B2BUA when you say "agent system"). > > Furthermore, there is a tradeoff in how general you make this header. The > reason we made Alert-Info and Call-Info separate things is that we want the > headers to be as precise as possible about what the purpose of the content > is. This ensures that the UA can treat it in an appropriate fashion for its > UI, and it also helps the UA perform appropriate filtering. For example, if > a UA gets a request with a Call-Info that contains an http URL with an > "icon" param, but the fetched content is an executable or VBscript, its a > safe bet its to be discarded. Not if the application is called Inhear :-) _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 01:09:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23045 for ; Mon, 22 Oct 2001 01:09:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA01143; Mon, 22 Oct 2001 00:40:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA01112 for ; Mon, 22 Oct 2001 00:40:57 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22734 for ; Mon, 22 Oct 2001 00:40:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9M4ck8P012364; Mon, 22 Oct 2001 00:38:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQVD9>; Mon, 22 Oct 2001 00:39:57 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: "'sip@ietf.org'" Subject: RE: [Sip] Open Issue #72: CANCEL for multicast Date: Mon, 22 Oct 2001 00:39:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Old thread, but we need resolution of it, and I have a proposal. Comments inline. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, September 26, 2001 10:54 PM > To: Jonathan Rosenberg > Cc: 'sip@ietf.org' > Subject: Re: [Sip] Open Issue #72: CANCEL for multicast > > > > > > I just don't see how this works under any amount of packet loss. > > My model is somewhat different: A proxy fronts three registrars, which > back up each other, but are on a local network in close > proximity to the > proxy server. In that case, packet loss is very unlikely, but > replication is very efficient and easy to implement. Well, you can't guarantee correctness in this case, which seems problematic. If you have only three registrars, it seems an awful lot easier and more robust to simply do a unicast fork to each of them. > > Lets say there are three registrars. A UAC sends a > multicast REGISTER, which > > is received by two of the three. The UAC will get two 200 > OK. According to > > the spec, it now stops retransmitting the request, since it > got a 200 OK. > > But, since the third registrar never got the request, the > registration is > > not updated there. > > > > To fix that, we'd have to basically retransmit continously > for a while, > > independent of any responses, in the hopes that we hit > every registrar. The > > client has no way to know if this succeeds. It results in > lots of network > > traffic, probably much less traffic than just sending three > separate unicast > > transactions. It also introduces another transaction model. > > > > To be honest, if you want to establish registration state > at multiple > > servers, you are much better off using time tested and well > understood > > database replication protocols in the back end between the servers. > > That's one approach, which assumes that there is a shared traditional > database. With in-memory databases, that's not nearly as easy. There are certainly solutions for that as well, which support in memory replication of data amongst a set of servers (i.e., TimesTen for example). Anyway, we are getting off track. My point was only that multicast is not a useful substitute for database replication protocols, which is what they are being used for here. > > > > The primary issue is that as specified, multicast operation > just doesn't > > work under anything but perfect conditions. So, it either > needs to be fixed, > > or if it can't be fixed and there are other ways to achieve > the same ends, > > it has to go. I don't want to be adding things, I want to > be removing them. > > Agreed. However, as discussed, multicast addresses a number > of problems > where other solutions may not exist (DHCP) or not be equivalent. The > complexity of this feature is extremely modest, so I don't see a large > gain in removing the feature, but I am afraid of removing a > useful tool. > It's a separate issue as to whether it makes sense to split this off > into a separate draft, similar to the SCTP-as-transport draft. As is, > not every registrar supports it, so this would not seem to imperil > interoperability beyond the current state. > I would not mind keeping it, if it weren't for the fact that so many things just break, or have to be declared as exceptions. For example: 1. response suppression, and even worse, the suppression is code specific 2. rules for matching responses to transactions don't work, since the via header is the same for each multicast recipient. Thus, there will often NOT be a way to disambiguate final responses from different recipients 3. request retransmission rules are different 4. proxy state machinery is different; since you don't know when you've gotten all responses, you have no way to know if its safe to forward a non-2xx upstream The result is that multicast is hard to implement, because exceptions for handling it are pervasive and significant. It is particularly problematic in bis-05, where we have taken a more layered approach to the protocol. Multicast introduces changes in all layers. Ideally, proxy processing should not depend on transport level issues, and that is completely true EXCEPT for multicast. So, my proposal is a compromise: Multicast remains, but its behavior is NO different than unicast at all layers of the protocol except transport (i.e., you expect the response via multicast). That is, when a client sends a multicast request, it expects, for non-invite, a single response. Any others would be discarded as retransmits, even if the code is different, or the tag is different. You stop retransmitting after the first response. There is no response suppression. In other words, protocol behavior treats multicast more like anycast, so that it assumes a single recipient, and treats responses as if that were the case. This means that a client sending a multicast register to a single registrar will work just fine. However, using multicast registers to replicate data across a set of registrars will not work under any packet loss greater than zero, but will work properly with zero packet loss. The limitations will need to be documented, of course. How is that? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 01:52:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25815 for ; Mon, 22 Oct 2001 01:52:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08843; Mon, 22 Oct 2001 01:17:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08819 for ; Mon, 22 Oct 2001 01:17:29 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23646 for ; Mon, 22 Oct 2001 01:17:27 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 21 Oct 2001 22:16:59 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Oct 2001 22:16:58 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 21 Oct 2001 22:16:58 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 21 Oct 2001 22:16:57 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Sun, 21 Oct 2001 22:16:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Sun, 21 Oct 2001 22:16:22 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC121BA32@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [Sip] 407s from different proxies on a SIP session Thread-Index: AcFaekjtlZrcYJiUQcey2qpxKtMhnAAPC6UA From: "Ajay Chitturi" To: "Jonathan Rosenberg" , "Robert Sparks" , , Cc: X-OriginalArrivalTime: 22 Oct 2001 05:16:23.0290 (UTC) FILETIME=[B0FC6DA0:01C15AB8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA08820 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit The consensus seems to be to use realm to identify the domain. Note that an example in the bis draft has realm="business". If there are two proxies challenging on the same realm, (esp. in the digest example that Jonathan described below) should we use the nonce ? Or should each proxy in the same domain also have a unique realm ? Thanks Ajay. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Sunday, October 21, 2001 2:50 PM To: Robert Sparks; Ajay Chitturi; aki.niemi@nokia.com; brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Friday, October 19, 2001 9:30 AM > To: 'Ajay Chitturi'; Robert Sparks; aki.niemi@nokia.com; > brett@broadsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] 407s from different proxies on a SIP session > > > Realm is defined in the DIGEST drafts to uniquely > identify a security domain. If more than one proxy > uses the same realm, they better accept the same > credentials. The username and password probably will be the same, but I suspect each proxy would generally choose separate nonces, so that two digest responses in two different Proxy-Authorization headers for the same realm would not be equally usable to both. > > A good nonce is going to be globally unique (using > the "extremely low probability of collision" definition > of uniqueness). I really think realm is the right thing, and we should specify one, and only one way to determine which credentials are "your own" for a proxy. I would rather mandate that realms be globally unique, probably using something like "com.dynamicsoft.serviceA" or some other such kind of hierarchy, as needed. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 03:19:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08394 for ; Mon, 22 Oct 2001 03:19:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11004; Mon, 22 Oct 2001 02:56:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10973 for ; Mon, 22 Oct 2001 02:56:18 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07490 for ; Mon, 22 Oct 2001 02:56:15 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9M6urf19866 for ; Mon, 22 Oct 2001 09:56:53 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Oct 2001 09:56:17 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 22 Oct 2001 09:55:54 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC3F@esebe013.NOE.Nokia.com> To: ajaych@windows.microsoft.com, jdrosen@dynamicsoft.com, rsparks@dynamicsoft.com, brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] 407s from different proxies on a SIP session Date: Mon, 22 Oct 2001 09:55:32 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > If there are two proxies challenging on the same realm, (esp. > in the digest example that Jonathan described below) should > we use the nonce ? Or should each proxy in the same domain > also have a unique realm ? Currently the realm is used for displaying to the user some information. It may have additional semantics, this is allowed in RFC 2617, but AFAIK doesn't have it now. It is totally up to the server to define its own namespace for the realm, because to the client, the Request-URI creates the uniqueness of each challenge/realm. E.g. realm="business" needs different credentials for domain.com and foobar.com. The server can't know which is which unless realm is specified to be something in the form of realm="business@foobar.com". Nonce won't help, since it can always be considered stale on proxies that don't store all sent challenges, but rather encode the state in the nonce. Cheers, Aki _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 10:41:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18881 for ; Mon, 22 Oct 2001 10:41:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21634; Mon, 22 Oct 2001 09:59:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21540 for ; Mon, 22 Oct 2001 09:59:30 -0400 (EDT) Received: from brtmailrelay.telecentrosul.com.br ([200.181.14.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17103 for ; Mon, 22 Oct 2001 09:59:26 -0400 (EDT) Received: from tcscorreiomb02.telecentrosul.com.br (200.181.14.134 [200.181.14.134]) by brtmailrelay.telecentrosul.com.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 460561NF; Mon, 22 Oct 2001 11:58:33 -0300 Received: by csuldns.telecentrosul.com.br with Internet Mail Service (5.5.2653.19) id <460718QW>; Mon, 22 Oct 2001 11:58:25 -0300 Message-ID: <756A402EE190D511AEC20002B33593AF016B94DA@TCSCORREIOMB03> From: Alexandre Ouriques de Castro To: sip@ietf.org Date: Mon, 22 Oct 2001 11:58:38 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B0A.0800B830" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C15B0A.0800B830 Content-Type: text/plain; charset="iso-8859-1" subscribe ------_=_NextPart_001_01C15B0A.0800B830 Content-Type: text/html; charset="iso-8859-1"

subscribe

------_=_NextPart_001_01C15B0A.0800B830-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 10:48:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18984 for ; Mon, 22 Oct 2001 10:48:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22380; Mon, 22 Oct 2001 10:17:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22356 for ; Mon, 22 Oct 2001 10:17:11 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17771 for ; Mon, 22 Oct 2001 10:17:07 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9MEHBY23980 for ; Mon, 22 Oct 2001 09:17:11 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9MEHA229951 for ; Mon, 22 Oct 2001 09:17:11 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Oct 22 09:17:10 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP0MS54>; Mon, 22 Oct 2001 09:17:09 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Jonathan Rosenberg'" , "'Alan Johnston'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Alert-Info: header Date: Mon, 22 Oct 2001 09:17:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B04.3C25EDC0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C15B04.3C25EDC0 Content-Type: text/plain; charset="iso-8859-1" >>This is fairly confusing if you assume that the Alert-Info: can >>only apply to ring(back) tone. If you broaden the header to mean >>"this is information to be rendered to the end user during the >>alerting period", then things start to make more sense. For example, >>if I send an http: URL in the Alert-Info: header in the INVITE, this >>could point to a thumbnail icon which provides an enhanced caller ID >>feature. > >I think this is what Call-Info was meant to do. In fact, an >"icon" parameter >has already been defined for this purpose exactly. Sorry, bad example. The point was to illustrate that there may be other useful information to render to the end user in the alerting phase. In particular, I want to stress that audio is not the only option here. >I, for one, had also thought that Alert-Info was meant as a >response header. >I don't see much use in the request for ringtone, since I >would expect that >ringtone is primarily going to be something the called party >selects, not >the caller. I don't see the harm in allowing either. I don't expect to mandate implementations to honor the Alert-Info: header. This is strictly optional behaviour. I just don't want some overzealous proxy in the middle discarding a request just because it has an Alert-Info: header. (I wish this were a hypothetical concern) >Whether its a new header, or a different header, the ability >for the caller >to specify content that the callee should render, play, or >whatever, is at >the same time both a powerful feature and a very dangerous >one. Of course. I hope everyone realizes the same about an INVITE. I'm not looking to add another capability to the Microsoft Virus Developers Kit. Given a reasonable amount of caution, I think this can be a useful header, in both directions. >I think its >important that the specification more clearly discuss the >security issues >here, and recommend that these headers only be followed for >calls that can >be authenticated. That doesn't mean that the called party needs to >authenticate the caller; one can imagine a system in a call >center where the >called party is an agent, and the agent system inserts these >headers after >identifying the caller through some means (IVR, or whatever). >So, as long as >the call comes from the agent system, the agent is safe in >rendering these >headers. Sure. The Call-Info: and Error-Info: headers should receive similar attention. > >Furthermore, there is a tradeoff in how general you make this >header. The >reason we made Alert-Info and Call-Info separate things is >that we want the >headers to be as precise as possible about what the purpose of >the content >is. This ensures that the UA can treat it in an appropriate >fashion for its >UI, and it also helps the UA perform appropriate filtering. >For example, if >a UA gets a request with a Call-Info that contains an http URL with an >"icon" param, but the fetched content is an executable or >VBscript, its a >safe bet its to be discarded. Understood. > >-Jonathan R. > >--- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com /sean ------_=_NextPart_001_01C15B04.3C25EDC0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Alert-Info: header

>>This is fairly confusing if you assume that the Alert-Info: can
>>only apply to ring(back) tone. If you broaden the header to mean
>>"this is information to be rendered to the end user during the
>>alerting period", then things start to make more sense. For example,
>>if I send an http: URL in the Alert-Info: header in the INVITE, this
>>could point to a thumbnail icon which provides an enhanced caller ID
>>feature.
>
>I think this is what Call-Info was meant to do. In fact, an
>"icon" parameter
>has already been defined for this purpose exactly.

Sorry, bad example. The point was to illustrate that there
may be other useful information to render to the end user
in the alerting phase. In particular, I want to stress that
audio is not the only option here.

>I, for one, had also thought that Alert-Info was meant as a
>response header.
>I don't see much use in the request for ringtone, since I
>would expect that
>ringtone is primarily going to be something the called party
>selects, not
>the caller.

I don't see the harm in allowing either. I don't expect to
mandate implementations to honor the Alert-Info: header. This
is strictly optional behaviour. I just don't want some overzealous
proxy in the middle discarding a request just because it has an
Alert-Info: header. (I wish this were a hypothetical concern)

>Whether its a new header, or a different header, the ability
>for the caller
>to specify content that the callee should render, play, or
>whatever, is at
>the same time both a powerful feature and a very dangerous
>one.

Of course. I hope everyone realizes the same about an INVITE.
I'm not looking to add another capability to the Microsoft
Virus Developers Kit. Given a reasonable amount of caution, I think
this can be a useful header, in both directions.

>I think its
>important that the specification more clearly discuss the
>security issues
>here, and recommend that these headers only be followed for
>calls that can
>be authenticated. That doesn't mean that the called party needs to
>authenticate the caller; one can imagine a system in a call
>center where the
>called party is an agent, and the agent system inserts these
>headers after
>identifying the caller through some means (IVR, or whatever).
>So, as long as
>the call comes from the agent system, the agent is safe in
>rendering these
>headers.

Sure. The Call-Info: and Error-Info: headers should receive
similar attention.

>
>Furthermore, there is a tradeoff in how general you make this
>header. The
>reason we made Alert-Info and Call-Info separate things is
>that we want the
>headers to be as precise as possible about what the purpose of
>the content
>is. This ensures that the UA can treat it in an appropriate
>fashion for its
>UI, and it also helps the UA perform appropriate filtering.
>For example, if
>a UA gets a request with a Call-Info that contains an http URL with an
>"icon" param, but the fetched content is an executable or
>VBscript, its a
>safe bet its to be discarded.

Understood.

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

/sean

------_=_NextPart_001_01C15B04.3C25EDC0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 11:50:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20608 for ; Mon, 22 Oct 2001 11:50:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24290; Mon, 22 Oct 2001 11:09:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24258 for ; Mon, 22 Oct 2001 11:09:13 -0400 (EDT) Received: from brtmailrelay.telecentrosul.com.br ([200.181.14.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19469 for ; Mon, 22 Oct 2001 11:09:08 -0400 (EDT) Received: from tcscorreiomb02.telecentrosul.com.br (200.181.14.134 [200.181.14.134]) by brtmailrelay.telecentrosul.com.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 460562K0; Mon, 22 Oct 2001 13:08:16 -0300 Received: by csuldns.telecentrosul.com.br with Internet Mail Service (5.5.2653.19) id <4607FALF>; Mon, 22 Oct 2001 13:08:09 -0300 Message-ID: <756A402EE190D511AEC20002B33593AF016B95AF@TCSCORREIOMB03> From: Alexandre Ouriques de Castro To: sip@ietf.org Date: Mon, 22 Oct 2001 13:08:19 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B13.C3F14600" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C15B13.C3F14600 Content-Type: text/plain; charset="iso-8859-1" subscribe ------_=_NextPart_001_01C15B13.C3F14600 Content-Type: text/html; charset="iso-8859-1"

subscribe

------_=_NextPart_001_01C15B13.C3F14600-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 12:14:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21576 for ; Mon, 22 Oct 2001 12:14:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25235; Mon, 22 Oct 2001 11:35:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25187 for ; Mon, 22 Oct 2001 11:35:10 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20110 for ; Mon, 22 Oct 2001 11:35:06 -0400 (EDT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GLM0043B5LY5E@firewall.wcom.com> for sip@ietf.org; Mon, 22 Oct 2001 15:27:34 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0GLM006015LPJM@pmismtp02.wcomnet.com> for sip@ietf.org; Mon, 22 Oct 2001 15:27:33 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0GLM004IA5LGTT@pmismtp02.wcomnet.com> for sip@ietf.org; Mon, 22 Oct 2001 15:27:16 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Oct 2001 15:27:16 +0000 Content-return: allowed Date: Mon, 22 Oct 2001 15:27:04 +0000 From: "McMurry, Kathleen" To: "'sip@ietf.org'" Message-id: <492EB4A3F68CD411ABE800508B69362E60500B@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_usDPiZ/arRHl/qCerLRKpA)" Subject: [Sip] Isomorphic Request Definition Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_usDPiZ/arRHl/qCerLRKpA) Content-type: text/plain; charset=ISO-8859-1 The definition of an Isomorphic Request was changed in one of the bis drafts to include the top-most Via header. My question regarding this is two-fold: 1) What call flow is it that requires the top-most Via header to be a part of this definition? The only reference to this I have seen is in the "Changes made in Version 02" section. That section indicates that "the Request-URI is the same for all BYE requests that are record-routed". This doesn't seem to be the case if the procedures detailed in Section 16.3 are followed. That section indicates that "the URL placed into the Record-Route header MUST be unique for each unique Request-URI in the request". 2) If there is a call flow that requires the top-most Via header to be a part of this definition, what is the appropriate behavior of a Proxy Server or UAS if the Request-URI, CallID, From, To, and CSeq are the same in a Request, but the top-most Via header is different? Some kind of error response? Thanks in advance for the clarification. Kathleen McMurry --Boundary_(ID_usDPiZ/arRHl/qCerLRKpA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Isomorphic Request Definition

The definition of an Isomorphic = Request was changed in one of the bis drafts to include the top-most = Via header.   My question regarding this is = two-fold:

1) What call flow is it that requires = the top-most Via header to be a part of this definition?  The only = reference to this I have seen is in the "Changes made in Version = 02" section.  That section indicates that "the = Request-URI is the same for all BYE requests that are = record-routed".  This doesn't seem to be the case if the = procedures detailed in Section 16.3 are followed.  That section = indicates that "the URL placed into the Record-Route header MUST = be unique for each unique Request-URI in the request".

2) If there is a call flow that = requires the top-most Via header to be a part of this definition, what = is the appropriate behavior of a Proxy Server or UAS if the = Request-URI, CallID, From, To, and CSeq are the same in a Request, but = the top-most Via header is different?  Some kind of error = response? 

Thanks in advance for the = clarification.

Kathleen McMurry



--Boundary_(ID_usDPiZ/arRHl/qCerLRKpA)-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 14:35:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26576 for ; Mon, 22 Oct 2001 14:35:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29811; Mon, 22 Oct 2001 13:55:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29785 for ; Mon, 22 Oct 2001 13:55:09 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25307 for ; Mon, 22 Oct 2001 13:55:05 -0400 (EDT) Received: from twinkie.cisco.com (twinkie.cisco.com [64.102.17.214]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9MHrnO29605 for ; Mon, 22 Oct 2001 13:53:49 -0400 (EDT) Received: from cisco.com (dhcp-64-102-92-118.cisco.com [64.102.92.118]) by twinkie.cisco.com (Mirapoint) with ESMTP id AGB03348 (AUTH wferrell); Mon, 22 Oct 2001 13:54:34 -0400 (EDT) Message-ID: <3BD45D0D.41D60073@cisco.com> Date: Mon, 22 Oct 2001 13:53:18 -0400 From: Wray Ferrell X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Session Timer - Timeout on Refresh Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Version 0.8 of the draft states: "If no response is received to a refreshing re_INVITE is received before the session expiration, the UA SHOULD send a BYE request to terminate the call. It SHOULD send this BYE slightly before session expiration." The bis-03 draft of SIP states under Reliability for INVITE Requests: "If no response is received after sending seven packet requests, processing continues as if a 481 response was received for that request." So does the SIP Session Timer override the section on reliability for INVITE requests? More specifically if a UA responsible for refreshing does not receive a response to it's re-INVITE what should it's behavior be? Disconnect the session as if receiving a 481 or keep the session alive since the session expiration has not yet been reached? Thanks, Wray _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Oct 22 16:54:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29630 for ; Mon, 22 Oct 2001 16:54:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05638; Mon, 22 Oct 2001 16:27:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05610 for ; Mon, 22 Oct 2001 16:27:38 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29147 for ; Mon, 22 Oct 2001 16:27:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9MKPGPI005506; Mon, 22 Oct 2001 16:25:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQXY8>; Mon, 22 Oct 2001 16:26:27 -0400 Message-ID: From: Sean Tang To: "'sip@ietf.org'" Cc: "'sip-implementors@cs.columbia.edu'" Date: Mon, 22 Oct 2001 16:26:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] authentication Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org If proxy server and user agent server both need to do authentication : UAC send INVITE to proxy, proxy send back 407 with a challenge. then UAC send a new INVITE with the credentials. Proxy forward this invite to UA server. UA server send back 401 with another challenge, UAC send a new INVITE with a new credentials, then proxy send back 407. So the double authentication never gonna succeed ? What is the solution to this scenaris ? _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 23 01:41:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09567 for ; Tue, 23 Oct 2001 01:41:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24942; Tue, 23 Oct 2001 01:11:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24871 for ; Tue, 23 Oct 2001 01:10:59 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07628 for ; Tue, 23 Oct 2001 01:10:40 -0400 (EDT) From: lkumar@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f9N5AsU06369; Tue, 23 Oct 2001 10:40:59 +0530 (IST) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by hsssun01.hss.hns.com (8.8.8+Sun/8.8.8) with SMTP id KAA11557; Tue, 23 Oct 2001 10:49:01 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256AEE.001BC6C0 ; Tue, 23 Oct 2001 10:33:23 +0530 X-Lotus-FromDomain: HSSBLR To: sip-implementors@cs.columbia.edu, sip@ietf.org Message-ID: <65256AEE.001BC638.00@sampark.hss.hns.com> Date: Tue, 23 Oct 2001 10:33:21 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] SDP over ATM. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I am just going thru the rfc-3108 and I understand that SIP (SDP rather) can be used to describe/control ATM bearer connetions and associated AALs. But I dont really understand the benifits of using SDP over other mechanisms.Are there any specific reasons/advantages or its just another way of signalling? I will be thankful if any body can help me out... Rgds, ~Lalit _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 23 08:17:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28087 for ; Tue, 23 Oct 2001 08:17:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07292; Tue, 23 Oct 2001 07:52:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07260 for ; Tue, 23 Oct 2001 07:52:44 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27153 for ; Tue, 23 Oct 2001 07:52:40 -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 HAA14247 for ; Tue, 23 Oct 2001 07:52:11 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01813 for ; Tue, 23 Oct 2001 07:52:11 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Oct 2001 07:52:11 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57C3D0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: sip@ietf.org Date: Tue, 23 Oct 2001 07:52:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Reminder from your list Administrator Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Never, EVER send the same message to 2 (or three) of sip, sipping or sip-implementors. People who do this are nearly 100% people who are puzzled by something and want to ask a question of people who know more than they do. The people that answer the questions are subscribed to all three lists, and thus they get multiple copies of the same email. This is annoying. Why annoy someone who may help you? CHOOSE ONE. If you don't know which one, use sip-implementors. The people who answer questions will direct the response to the proper list if you have chosen incorrectly. There have been quite a few emails sent to multiple lists in the past couple of days. Didn't I just send a message about this not so long ago? Thank you for your support Brian _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 23 16:17:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18737 for ; Tue, 23 Oct 2001 16:17:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22315; Tue, 23 Oct 2001 15:48:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22284 for ; Tue, 23 Oct 2001 15:48:36 -0400 (EDT) Received: from imo-r04.mx.aol.com (imo-r04.mx.aol.com [152.163.225.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17739 for ; Tue, 23 Oct 2001 15:48:32 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v31_r1.8.) id l.13d.3553074 (4398) for ; Tue, 23 Oct 2001 15:48:26 -0400 (EDT) Message-ID: <13d.3553074.2907238a@aol.com> Date: Tue, 23 Oct 2001 15:48:26 EDT To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 112 Content-Transfer-Encoding: 7bit Subject: [Sip] Priority request-header values Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit To all, The current 2543bis defines the Priority request-header field as follows: Priority = "Priority" ":" priority-value Priority-value = "emergency" | "urgent" | "normal" | "non-urgent" | other-priority other-priority = token (It isn't explained what "other-priority=token" means, but I suppose those deeply involved in the protocol understand this.) I find no explicit statement about the ordering of these values, although one might infer the order from the meaning of the (English) words. But I really can't decide the relationship between "routine" and "non-urgent". They sound synonomous to me. This does not satisfy the requirement of the US military networks for possible use of SIP for mission critical traffic. The requirement for the US military, based on long-standing national and international telecommunications standards, is for five levels of precedence, namely: "Flash Override", "Flash", "Immediate", "Priority", and "Routine" (in English). Of course, other countires which use the same standard might use different words to represent the levels (to a human). The machine, and the network elements, do not need to know or deal with these English words. They only need to know the relationship between the values. We require the definition of a field to carry the precedence (often called priority) level in the form of a number from 0-4, with an explicit definition that 0 is the highest priority. Its association with the local language or the words used for the specific network is not a matter for the standard. The preferable solution would be to define a 4 bit field and assign 5 values, exactly as is defined in draft-ietf-mpls-cr-ldp-05 of March 2001. Since it is probable that most would not agree to changing the present (RFC2543) definitions, it would then seem appropriate to make the change in 2543bis to add five new values to the current four, as follows: "level0" | "level1" | "level2" | "level3" | "level4" and to add the following statement: When the values "level0" through "level4" are used, they must be interpreted as an ordered set such that level0 > level1 > level2 > level3 > level4 (in relation to their treatment to prioritize call handling operations). No explicit ordering of "emergency", "urgent", "normal", and "non-urgent" or their relation to level0 through level4 is defined. This constant use of specific English words rather than numeric values is causing the protocol and its processing to become less efficient and is leading to complications in the definition, as in the recent spate of e-mails regarding the meaning of the ANI-II digits. It is also causing difficulties in attempts to internationalize (or rather de-Americanize) the definitions of the Internet Protocol. I think it is time for a major change in the approach being used to define such protocols. Mike Pierce _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Oct 23 18:39:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21830 for ; Tue, 23 Oct 2001 18:39:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26253; Tue, 23 Oct 2001 18:16:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26221 for ; Tue, 23 Oct 2001 18:16:01 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21552 for ; Tue, 23 Oct 2001 18:15:57 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9NMEiO14387 for ; Tue, 23 Oct 2001 18:14:44 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAC43383 (AUTH pkyzivat); Tue, 23 Oct 2001 18:16:52 -0400 (EDT) Message-ID: <3BD5EB8F.BCBB5757@cisco.com> Date: Tue, 23 Oct 2001 18:13:35 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org References: <004901c158ad$fa5d2780$1fe4b4cc@laptopeng3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Inconsistency/ambiguity in Contact header syntax Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Section 10.14 of draft-ietf-sip-rfc2543bis-04.txt says: Contact = ( "Contact" | "m" ) ":" ("*" | (1# (( name-addr | addr-spec ) *( ";" contact-params )))) contact-params = "q" "=" qvalue | "action" "=" "proxy" | "redirect" | "expires" "=" delta-seconds | <"> SIP-date <"> | contact-extension expires: The "expires" parameter indicates how long the URI is valid. The parameter is either a number indicating seconds or a quoted string containing a SIP-date. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. while section 7.6 says: Registrations expire as described above or may be removed explicitly by setting the expires parameter for an existing registration to zero or including an Expires: 0 header field. Registrations are matched based on the user, host, port and maddr parameters. A client can remove all registrations by including a single Contact header field with the wildcard address "*". This usage is only allowed in REGISTER requests when a Expires header with value of zero is present. Accordingly, the following seems to be correct: REGISTER ... Expires: 5 Contact: sip:foo@bar.com;expires=0 Contact: sip:goo@bar.com Contact: sip:zoo@bar.com while the following is apparently incorrect: REGISTER ... Expires: 5 Contact: *;expires=0 Contact: sip:goo@bar.com Contact: sip:zoo@bar.com Also, while the text in 7.6 says the "Contact: *" usage is only allowed when an "Expires: 0" header is present, it doesn't forbid the use of parameters with this header. So the following seems to be legal: REGISTER ... Expires: 0 Contact: *;expires=0;q=0.5 And the following seems to be syntactically ok but semantically questionable: REGISTER ... Expires: 0 Contact: *;expires=5 This seems to have been made obscure by virtue of too much special casing. I would think the following revised wording for 7.6 would make a lot more sense: Registrations expire as described above or may be removed explicitly by setting the expires parameter for an existing registration to zero or including an Expires: 0 header field. Registrations are matched based on the user, host, port and maddr parameters. A client can remove all prior registrations by including a Contact header field with the wildcard address "*". A wildcard address of "*" may only used in a Contact header in a REGISTER request, and only with an expiration time (explicit or implicit) of zero. Paul Kyzivat Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 24 02:43:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15890 for ; Wed, 24 Oct 2001 02:43:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12661; Wed, 24 Oct 2001 01:24:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12630 for ; Wed, 24 Oct 2001 01:24:48 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02360 for ; Wed, 24 Oct 2001 01:24:31 -0400 (EDT) From: seshashayi@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f9O5PCH29549; Wed, 24 Oct 2001 10:55:12 +0530 (IST) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by hsssun01.hss.hns.com (8.8.8+Sun/8.8.8) with SMTP id LAA03812; Wed, 24 Oct 2001 11:03:22 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256AEF.001D15E3 ; Wed, 24 Oct 2001 10:47:41 +0530 X-Lotus-FromDomain: HSSBLR To: Paul Kyzivat cc: sip@ietf.org Message-ID: <65256AEF.001D14F4.00@sampark.hss.hns.com> Date: Wed, 24 Oct 2001 10:47:49 +0530 Subject: Re: [Sip] Inconsistency/ambiguity in Contact header syntax Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, The ABNF for Contact, if you look carefully , doesn't allow any contact params to exist, in case of the wild card address. Contact = ("Contact" | "m" ) ":" ( "*" | (1#((name-addr|addr-spec ) *(";"contact-params ))) ) So, the following is not syntactically correct: Contact: *;expires=4 I think that should solve the problem.. Rgds Seshu Paul Kyzivat on 10/24/2001 03:43:35 AM To: sip@ietf.org cc: (bcc: Seshashayi T/HSSBLR) Subject: [Sip] Inconsistency/ambiguity in Contact header syntax Section 10.14 of draft-ietf-sip-rfc2543bis-04.txt says: Contact = ( "Contact" | "m" ) ":" ("*" | (1# (( name-addr | addr-spec ) *( ";" contact-params )))) contact-params = "q" "=" qvalue | "action" "=" "proxy" | "redirect" | "expires" "=" delta-seconds | <"> SIP-date <"> | contact-extension expires: The "expires" parameter indicates how long the URI is valid. The parameter is either a number indicating seconds or a quoted string containing a SIP-date. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. while section 7.6 says: Registrations expire as described above or may be removed explicitly by setting the expires parameter for an existing registration to zero or including an Expires: 0 header field. Registrations are matched based on the user, host, port and maddr parameters. A client can remove all registrations by including a single Contact header field with the wildcard address "*". This usage is only allowed in REGISTER requests when a Expires header with value of zero is present. Accordingly, the following seems to be correct: REGISTER ... Expires: 5 Contact: sip:foo@bar.com;expires=0 Contact: sip:goo@bar.com Contact: sip:zoo@bar.com while the following is apparently incorrect: REGISTER ... Expires: 5 Contact: *;expires=0 Contact: sip:goo@bar.com Contact: sip:zoo@bar.com Also, while the text in 7.6 says the "Contact: *" usage is only allowed when an "Expires: 0" header is present, it doesn't forbid the use of parameters with this header. So the following seems to be legal: REGISTER ... Expires: 0 Contact: *;expires=0;q=0.5 And the following seems to be syntactically ok but semantically questionable: REGISTER ... Expires: 0 Contact: *;expires=5 This seems to have been made obscure by virtue of too much special casing. I would think the following revised wording for 7.6 would make a lot more sense: Registrations expire as described above or may be removed explicitly by setting the expires parameter for an existing registration to zero or including an Expires: 0 header field. Registrations are matched based on the user, host, port and maddr parameters. A client can remove all prior registrations by including a Contact header field with the wildcard address "*". A wildcard address of "*" may only used in a Contact header in a REGISTER request, and only with an expiration time (explicit or implicit) of zero. Paul Kyzivat Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Oct 24 09:29:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27711 for ; Wed, 24 Oct 2001 09:29:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24102; Wed, 24 Oct 2001 08:44:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24071 for ; Wed, 24 Oct 2001 08:44:25 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25242 for ; Wed, 24 Oct 2001 08:44:23 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9OCh8O04480; Wed, 24 Oct 2001 08:43:08 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAC45620 (AUTH pkyzivat); Wed, 24 Oct 2001 08:45:17 -0400 (EDT) Message-ID: <3BD6B716.845E0FAA@cisco.com> Date: Wed, 24 Oct 2001 08:41:58 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: seshashayi@hss.hns.com CC: sip@ietf.org Subject: Re: [Sip] Inconsistency/ambiguity in Contact header syntax References: <65256AEF.001D14F4.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit OK, you are right - I counted parens wrong. Paul seshashayi@hss.hns.com wrote: > > Hi, > The ABNF for Contact, if you look carefully , doesn't allow any contact > params to exist, in case of the > wild card address. > > Contact = ("Contact" | "m" ) ":" ( "*" | (1#((name-addr|addr-spec ) > *(";"contact-params ))) ) > > So, the following is not syntactically correct: > Contact: *;expires=4 > > I think that should solve the problem.. > > Rgds > Seshu > > Paul Kyzivat on 10/24/2001 03:43:35 AM > > To: sip@ietf.org > cc: (bcc: Seshashayi T/HSSBLR) > > Subject: [Sip] Inconsistency/ambiguity in Contact header syntax > > Section 10.14 of draft-ietf-sip-rfc2543bis-04.txt says: > > Contact = ( "Contact" | "m" ) ":" > ("*" | (1# (( name-addr | addr-spec ) > *( ";" contact-params )))) > contact-params = "q" "=" qvalue > | "action" "=" "proxy" | "redirect" > | "expires" "=" delta-seconds | <"> SIP-date <"> > | contact-extension > > expires: The "expires" parameter indicates how long the URI is > valid. The parameter is either a number indicating seconds > or a quoted string containing a SIP-date. If this parameter > is not provided, the value of the Expires header field > determines how long the URI is valid. Implementations MAY > treat values larger than 2**32-1 (4294967295 seconds or 136 > years) as equivalent to 2**32-1. > > while section 7.6 says: > > Registrations expire as described above or may be removed explicitly > by setting the expires parameter for an existing registration to zero > or including an Expires: 0 header field. Registrations are matched > based on the user, host, port and maddr parameters. A client can > remove all registrations by including a single Contact header field > with the wildcard address "*". This usage is only allowed in REGISTER > requests when a Expires header with value of zero is present. > > Accordingly, the following seems to be correct: > > REGISTER ... > Expires: 5 > Contact: sip:foo@bar.com;expires=0 > Contact: sip:goo@bar.com > Contact: sip:zoo@bar.com > > while the following is apparently incorrect: > > REGISTER ... > Expires: 5 > Contact: *;expires=0 > Contact: sip:goo@bar.com > Contact: sip:zoo@bar.com > > Also, while the text in 7.6 says the "Contact: *" usage is only allowed > when an "Expires: 0" header is present, it doesn't forbid the use of > parameters with this header. > So the following seems to be legal: > > REGISTER ... > Expires: 0 > Contact: *;expires=0;q=0.5 > > And the following seems to be syntactically ok but semantically > questionable: > > REGISTER ... > Expires: 0 > Contact: *;expires=5 > > This seems to have been made obscure by virtue of too much special > casing. I would think the following revised wording for 7.6 would make a > lot more sense: > > Registrations expire as described above or may be removed explicitly > by setting the expires parameter for an existing registration to zero > or including an Expires: 0 header field. Registrations are matched > based on the user, host, port and maddr parameters. A client can > remove all prior registrations by including a Contact header field > with the wildcard address "*". A wildcard address of "*" may only > used > in a Contact header in a REGISTER request, and only with an > expiration > time (explicit or implicit) of zero. > > Paul Kyzivat > Cisco Systems > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 24 16:05:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13243 for ; Wed, 24 Oct 2001 16:05:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27520 for sip-archive@odin.ietf.org; Wed, 24 Oct 2001 16:05:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26667; Wed, 24 Oct 2001 15:38:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26636 for ; Wed, 24 Oct 2001 15:38:55 -0400 (EDT) Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12664 for ; Wed, 24 Oct 2001 15:38:53 -0400 (EDT) Received: from adsl-64-169-17-213.dsl.snfc21.pacbell.net (HELO rwc-jfmule01.yahoo.com) (64.169.17.213) by smtp.mail.vip.sc5.yahoo.com with SMTP; 24 Oct 2001 19:38:55 -0000 X-Apparently-From: Message-Id: <5.1.0.14.2.20011024122225.00ad6840@pop.mail.yahoo.com> X-Sender: jfmule@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Oct 2001 12:38:22 -0700 To: Tom-PT Taylor From: Jean-Francois Mule Cc: sip@ietf.org, klingle@cisco.com, jmaeng@ipdialog.com, jfmule@yahoo.com, drwalker@ss8.com In-Reply-To: <000101c15cc0$d55bbd40$d511a940@rwcjfmule01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] Re: Review of draft-ietf-sip-mib-03.txt Part 1 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Tom, This email summarizes our responses to Tom Taylor's comments Part 1 received on 10/01/2001. Please review & comment as we need more clarifications on some of the comments you submitted. Thank you for your comments on ietf-sip-mib-draft03. Jean-Francois. > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Monday, October 01, 2001 10:46 AM > To: 'sip@ietf.org' > Cc: 'klingle@cisco.com'; 'jmaeng@ipdialog.com'; 'jfm@clarent.com'; > 'drwalker@ss8.com' > Subject: Review of draft-ietf-sip-mib-03.txt Part 1 > > > Time I got this out, just to get discussion going. The rest > will follow soon. > > Substantive Issues > ================== > > Section 5.2: > ----------- > sipServiceOperStatus: since the status values are supposed to > be mapped > to applOperStatus, why not just use the values of the latter, adding > values above them where they are lacking? > > Currently: > applOperStatus: up(1), down(2), halted(3), congested(4), > restarting(5), quiescing(6) > sipServiceOperStatus: up(1), down(2), testing(3), unknown(4), > halted(5), restarting(6) agreed, we need the 2 to converge; see the rewrite proposal sent on the mailing list on 10/12- jfm, fixed. > sipServiceAdminStatus: > - What value would be read when the entity is operating normally? see new proposal; when this object is queried, get a noop value return. " Setting this object to a value of noop(1) has no effect. When read, this object always has a value of noop(1)." > - The descriptions of the values should indicate what > operational status transitions they bring about. the correlation is now clear based on the rewrite - jfm, fixed. > sipServiceStartTime, sipServiceLastChange DESCRIPTION: > sysUpTime is not > defined -- should there be a reference? no need to reference the def of sysUpTime (rfc1213, mib 2) this is too common, kevin, done. > sipMaxSessions: is "session" equivalent to call-leg in a UA, > transaction > in any other entity? Should the description say so? What > value is put in for a stateless proxy? sipMaxSessions: In the beginning, we had sipMaxCalls. Based on rfc2543bis04, we propose to rename this object back to sipMaxCalls as the notion of call is defined. It seems that the term session is only defined in SIP in the context of SDP session. It seems you can have multiple call-legs per session. > sipInviteTimeOut: appears to apply only to UAs, hence may > belong in the > SIP-UA-MIB. We need a corresponding entry for default registration > timeouts, at both the UAC and the Registrar ends. 1/ we think the object sipInviteTimeOut could be used by call stateful proxies as well. 2/ We agree we have an issue for the default registration timeouts in uac. We propose to add sipRegContactDfltExpiryDuration object to sipuamib as we had before in server mib draft-02 w/ some description changes. => kevin to take first stab at the objects. > General comment: should it be possible to retrieve on a > read-only basis > the capabilities of the SIP entity as expressed in the Allow, > Supported, and Accept headers respectively? Supported has its > equivalent in the sipFtrSupportedTable, but the other items also need > definition. More clarification is requested. 1. do you suggest to add a table reflecting the headers an implementation supports? 2. do you suggest to add another object in that table that give more details per header of what capabilties are there? => any comments from the group on that topic? useful, not useful... > Might want a read-write object corresponding to Accept-Language. RFC2543 section 6.9, uses a string to indicate preference for language. Are you asking for an additional object of type string to configure this? (=> Kevin, to insert sip common config table upon confirmation) > sipFtrSupported: should this have provision for feature version? Or > will new versions mean new option tags? no, it's a string for non-std features, vendors can include their own version info in the string if desired. > sipCommonCfgTimerxxx: Do we really need timer settings per > method? The > RFC 2543bis description of behaviour distinguishes between two > transmission timing situations: regular requests (not INVITE > or ACK) vs. > INVITE. For the former we actually need two timer settings: for the > initial value T1 and the upper bound T2. For INVITE we need just T1, > which could differ from the T1 for other methods. We also, > absolutely, > need the application-level timer defined as sipCfgTimerProv. based on your second email, issues resolved or moot. > sipCfgRetryxxx: are these meant to control the number of times a > transaction of the given type will be reinitiated when the previous > attempt has met with 4xx or 5xx failure or has died due to > reaching the > retransmission limit? This would be like the automatic > retries done by > a FAX machine, but I suspect it wouldn't be generally useful -- better > to rely on user reinitiation except perhaps for REGISTER requests. Or > do they set the maximum number of retransmissions? The latter control > is not needed: the maximum number of retransmissions is set > unequivocally by the RFC. based on your second email, issues resolved or moot. > sipCfgRetryNonFinalResponse: clearly meant for retransmissions, and > useless unless the 100rel feature is being used. yes, true, this was added in the context of 183 with SDP discussions which led to the 100rel discussion and draft. This object is still be useful in that context, we suggest to keep it. > Nits and editorial > ================== > Need an IANA Considerations section. What do you mean exactly? Do you mean we need to add a generic IANA consideration section about the oid registration for e.g. Do you have any specific items in mind like for example the applName values for sip entities? any other object values??? ... just want to make sure we get the full comment here. > General: capitalize MUST, SHOULD, SHOULD NOT, MAY. yes. Updated front/backmatter sections - jfm, done. question: do you mean inside the mib too? => kevin > Section 4: > ----------- > first para (top of p. 4): slight redundancy, slightly garbled. I > suggest that the fourth and fifth sentences be replaced by: > > "SIP-COMMON-MIB contains common objects used in all the SIP entities. > SIP-SERVER-MIB contains objects for Registrars, Proxies, and Redirect > servers, and SIP-UA-MIB contains objects for User Agents." Updated 04alpha revision doc, done. kept tom's first sentence as-is, modified second sentence as follows: "SIP-SERVER-MIB contains objects specific to Registrars, Proxies and Redirect servers, and SIP-UA-MIB includes objects specific to User Agents." > Next para: change "Each MIB Module contain following.." to "The MIB > Modules contain the following.." agreed; done. > The final para, after the list of MIB contents, might more > clearly read: > > "To conform with this specification, an SNMP agent MUST implement > SIP-MIB-SMI, SIP-TC, plus one instance of SIP-COMMON-MIB and one > instance of the SIP entity-type-specific MIB (SIP-SERVER-MIB or > SIP-UA-MIB) as applicable for each instance of a SIP entity being > managed. Section 4.2 describes handling of multiple instances in > detail." ok, changed to "To conform with this specification, an SNMP agent MUST implement SIP-TC, plus one instance of SIP-COMMON-MIB and one instance of the SIP entity-type-specific MIB (SIP-SERVER-MIB or SIP-UA-MIB) as applicable for each instance of a SIP entity being managed. If a device has more than one sip entity or multiple instances of the same entity, it SHOULD implement multiple SIP modules. Section 4.2 describes handling of multiple instances in detail." > Section 4.2: > ----------- > First para: I suggest this sentence be inserted after the first > sentence, to capture your thought: > " ...SNMP agent. This can happen because the same system supports > multiple SIP entity types." ok, added - jfm. > Second para is really unclear and somewhat redundant with > section 4. I > suggest it be rewritten as follows (if I have understood > correctly what > you meant to say): > > "In either case, the operator may choose to represent the system as an > aggregate entity, requiring one copy of the SIP-COMMON-MIB > and a copy of > the SIP-SERVER-MIB and/or the SIP-UA-MIB as required. Alternatively, > each SIP entity instance may be associated with its own copy of the > SIP-COMMON-MIB and its own copy of the SIP entity-type-specific MIB. > This latter mode of operation provides the requirement for supporting > multiple instances of a particular MIB module in one system." we agree this need to be looked at. We will rewrite the text. => kevin to work on cleaning up the paragraph. > I suggest you add this sentence at the end of the third para to make > clear what applIndex is being used for: > "The applIndex is then used to distinguish SIP entity instances in the > SIP-COMMON-MIB and the SIP entity-type-specific MIBs." ok, jfm, done > Description of how to populate applName, final bullet beginning "for a > SIP entity acting in...": suggest it begin as follows: > > " o For any combination of Proxy, Registrar, or Redirect Server being > managed as a single aggregate entity, the applName ... " ok, jfm, done > Next para, beginning "Additionally, the following objects ..." can be > rewritten to reduce redundancy and at the same time eliminate the note > following the specific object mappings if it is written as follows: > > "The SNMP agent MAY support any combination of the other attributes in > applTable. If the following objects are supported, the object values > SHOULD ..." ok, jfm, done > In the bullets for applUptime and applLastChange, SIP-COMMON should be > SIP-COMMON-MIB. ok, jfm, fixed. > Example 1: suggest the first sentence be modified slightly to read: > "The tables below illustrate how a system acting as both Proxy and > Registrar server might be configured to maintain separate > SIP-COMMON-MIB > instances." jfm, ok, done. > In the rest of the example, change "would be populated" and "is > populated" to "might be populated". jfm, ok, done. > Example 2: modify the first sentence to read: > This example illustrates how to represent a system acting as > both Proxy > and Registrar server, where the two entities share a single > instance of SIP-COMMON-MIB. jfm, ok, done. > Section 5.2: > ----------- > sipCommonMIB DESCRIPTION: don't repeat the definitions of the > different > entities -- just refer back to the 2543 definitions section. we (Kevin and jean-francois) disagree. It is good to have them right in the mib for nm admins and it is not that long. > sipCommonCfgEntry DESCRIPTION: insert the word "instance" > after the word > "entity" at the beginning of the second line. (The word > "those" is not needed in the first line.) ok, done. > sipOrganization DESCRIPTION: suggest the description (which currently > quotes the definition of the Organization header) be modified to read: > > "This object contains the organization name which the SIP > entity inserts > into Organization headers which it adds to SIP messages > processed by it. > If the string is empty no Organization header is to be generated." ok => KEVIN - udpate to mib modules jfm to update to doc, done. > sipPortStatus: description should say whether elements of the > row can be > modified when RowStatus is Active. we agree some txt should be added. => kevin to propose text. > sipFtrSupported: the description should indicate whether the complete > path (i.e. org.ietf.sip.xxx) has to be entered for IETF-standardized > features. We will add the following "For IETF standardized features, the complete path (eg, org.ietf.sip.xxx) should be reflected in this table. => kevin - add this after last sentence in 3rd para (starting w/ Similarly,..), kevin to update the mib jfm - updated the doc, done. > sipCfgInitialTimerInvite: description should specify that this is the > initial value T1 for the retransmission timer. based on later email received from you, we assume this comment is no longer valid. > References: > ---------- > [18]: misprinted name, quotation marks. Should be: > N. Freed, S. Kille, "Network Services Monitoring MIB", ... ok, fixed. Thanks a lot for all the comments. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 24 18:52:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16168 for ; Wed, 24 Oct 2001 18:52:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01780 for sip-archive@odin.ietf.org; Wed, 24 Oct 2001 18:52:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00852; Wed, 24 Oct 2001 18:25:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00794 for ; Wed, 24 Oct 2001 18:24:56 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15499; Wed, 24 Oct 2001 18:24:54 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OMN5PI024213; Wed, 24 Oct 2001 18:23:05 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 18:24:16 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" , "SIPPINGWG Mailing List (sipping@ietf.org)" Date: Wed, 24 Oct 2001 18:24:12 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA00795 Subject: [Sip] Last Call Coordinator Request Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello Everyone, I wanted to thank everyone who has helped in the last call process in the last eight months that I have been involved. I have recently seen a marked slow down in responses to my requests to conduct reviews and even when a review is agreed to I don't always see a follow through. A list of people who have volunteered is listed at http://www.softarmor.com/sipwg/lastcall/lcassignments.pl for the SIP WG or at http://www.softarmor.com/sipping/lastcall/lcassignments.pl for the SIPPING WG (both lists are the same). This list also identifies who has conducted what review. Please let me know if you are unable to participate any longer. If you would like to be added to the list, please contact me. Additionally, there seems to be very little discussion on the list of drafts that have been opened for last call discussion. This is your opportunity to mold the final draft. Please make use of this. Once we close the last call discussion the authors will update the draft and we will send it on to IESG. I am here to help the working group and it is a pleasure to do so. If you have any suggestions on how we can do this better, please don't hesitate to contact me. Regards,   Rakesh ______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 (973) 952-5000 main (973) 952-5066 direct (201) 214-6084 mobile (973) 952-5050 fax rshah@dynamicsoft.com www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 24 19:15:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16668 for ; Wed, 24 Oct 2001 19:15:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02769 for sip-archive@odin.ietf.org; Wed, 24 Oct 2001 19:15:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01867; Wed, 24 Oct 2001 18:53:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01838 for ; Wed, 24 Oct 2001 18:53:04 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16200 for ; Wed, 24 Oct 2001 18:53:01 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OMpOPI024461 for ; Wed, 24 Oct 2001 18:51:24 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 18:52:35 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" Date: Wed, 24 Oct 2001 18:52:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA01839 Subject: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Just a reminder to this draft's reviewers to post their reviews to the list. The last call discussion has been opened on the list and is due to close on 12Nov01. Regards,   Rakesh ______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 (973) 952-5000 main (973) 952-5066 direct (201) 214-6084 mobile (973) 952-5050 fax rshah@dynamicsoft.com www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 24 19:20:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16776 for ; Wed, 24 Oct 2001 19:20:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02871 for sip-archive@odin.ietf.org; Wed, 24 Oct 2001 19:20:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02026; Wed, 24 Oct 2001 18:57:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01995 for ; Wed, 24 Oct 2001 18:57:34 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16290 for ; Wed, 24 Oct 2001 18:57:31 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OMtsPI024503 for ; Wed, 24 Oct 2001 18:55:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 18:57:05 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" Date: Wed, 24 Oct 2001 18:57:01 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-call-auth -02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dear SIP WG Members, The subject draft (link below) is going through WGLC. The assigned reviewers have or should be posting their initial comments on the list. The Last Call Open Discussion will be closed on 17Nov01. Please post your comments to the list. The authors will be collecting this input and addressing issues. The authors will post a summary at the end of this part of the last call process. If you have any further questions, please feel free to contact me. Links Draft - http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-call-auth-02.txt Last Call Calendar - http://www.softarmor.com/sipwg/lastcall/lccalendar.pl Reviewer's page - http://www.softarmor.com/sipwg/lastcall/reviewerinfo.html Supplemental SIP WG Web site - http://www.softarmor.com/sipwg Regards, Rakesh ______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 (973) 952-5000 main (973) 952-5066 direct (201) 214-6084 mobile (973) 952-5050 fax rshah@dynamicsoft.com www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 24 20:14:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16665 for ; Wed, 24 Oct 2001 19:15:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02768 for sip-archive@odin.ietf.org; Wed, 24 Oct 2001 19:15:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01701; Wed, 24 Oct 2001 18:48:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01669 for ; Wed, 24 Oct 2001 18:48:42 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16056 for ; Wed, 24 Oct 2001 18:48:40 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OMl3PI024348 for ; Wed, 24 Oct 2001 18:47:03 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 18:48:14 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" Date: Wed, 24 Oct 2001 18:48:13 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] SIP WG - 6 - Last Call Open Discussion CLOSED - draft-ietf-sip-mi b-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dear SIP WG Members, The subject draft's (link below) Open Discussion is now closed. The authors should be posting their summaries on the list shortly. Thank you for your participation in this discussion. The next step is to poll the chairs and submit an updated draft to the IESG. If you have any further questions, please feel free to contact me. Links Draft - http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-mib-03.txt Last Call Calendar - http://www.softarmor.com/sipwg/lastcall/lccalendar.pl Supplemental SIP WG Web site - http://www.softarmor.com/sipwg Regards, Rakesh ______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 (973) 952-5000 main (973) 952-5066 direct (201) 214-6084 mobile (973) 952-5050 fax rshah@dynamicsoft.com www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 03:06:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10971 for ; Thu, 25 Oct 2001 03:06:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22687 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 03:06:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21627; Thu, 25 Oct 2001 02:32:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21598 for ; Thu, 25 Oct 2001 02:32:11 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08509 for ; Thu, 25 Oct 2001 02:32:08 -0400 (EDT) Received: from lohi.eng.telia.fi (localhost [127.0.0.1]) by lohi.eng.telia.fi (8.12.1/8.12.1/Debian -2) with ESMTP id f9P6W1Sc008043; Thu, 25 Oct 2001 09:32:01 +0300 Received: (from jh@localhost) by harjus.eng.song.fi (8.12.1/8.12.1/Debian -2) id f9P6TVgl001313; Thu, 25 Oct 2001 09:29:31 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15319.45386.993016.801025@harjus.eng.song.fi> Date: Thu, 25 Oct 2001 09:29:30 +0300 To: Rakesh Shah Cc: "SIPWG Mailing List (sip@ietf.org)" Subject: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt In-Reply-To: References: X-Mailer: VM 6.96 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit as a general comment i have to say that the idea of interleaving an end-to-end resource reservation mechanism with sip signaling sounds an overkill that will introduce lots of new complexity, delay, and processing in the network devices to the call setup process. i thus wonder if it will ever be deployed in practise in any large scale. lets consider cellular calls as an exaple, which is likely to be the environment, where the reseource problem will be the greatest. there we don't need any end-to-end reservation protocol, such as rsvp, to check that the resources are available. the calling party can simply first try to create a new real time pdp context for the call and if that succeeds, he knows that local resources are available. when the invite hits the called cell phone, it too tries first create a new real time pdp context for this call and if that succeeds, the phone will ring and an ok will be send back to the calling party. the packets will then be marked with a diffserv code point indicating that they should use the real time pdp context. some of the details are missing from the above example, but it should serve to illustrate my point. the question thus remains, do we really need in real life the complexity of manyfolks-resource? if it is likely that other solutions might also work and be widely deployed, the i-d should say so. otherwise readers might get the impression that this is THE way to implement qos for sip calls. may be i missed it, but the i-d should also try to analyze if the mechanism will scale if every phone call in the world would use it and how much additional delay will be introduced by it to the call setup process. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 05:14:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12107 for ; Thu, 25 Oct 2001 05:14:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA27081 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 05:14:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26231; Thu, 25 Oct 2001 04:56:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26199 for ; Thu, 25 Oct 2001 04:56:52 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11927 for ; Thu, 25 Oct 2001 04:56:41 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9P8uLC17652; Thu, 25 Oct 2001 10:56:21 +0200 (MEST) Received: from ericsson.com (E0080C7779971.lmf.ericsson.se [131.160.30.9]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9P8uKB13514; Thu, 25 Oct 2001 11:56:20 +0300 (EET DST) Message-ID: <3BD7D3B2.ECDD094A@ericsson.com> Date: Thu, 25 Oct 2001 11:56:18 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Rakesh Shah CC: "SIPWG Mailing List (sip@ietf.org)" , William Marshall Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: I'm not sure if I shout this comment publicly, but just in case I didn't, here it goes: Manyfolks should clearly state that the SDP returned in the 200 OK for the INVITE MUST NOT be used to change the "agreed" SDP negotiated in the INVITE, 183 (and PRACK) process. The SDP in the 200 OK MUST be sent to allow backward compatibility of middle proxies, but not to change the SDP itself. If such a change is needed, the UA should re-INVITE. I hope this clarification is acceptable and can be incorporated to the text. /Miguel Rakesh Shah wrote: > > Just a reminder to this draft's reviewers to post their reviews to the list. > > The last call discussion has been opened on the list and is due to close on > 12Nov01. > > Regards, > > Rakesh > ______________________________ > Mr. Rakesh C. Shah > Project Coordinator > dynamicsoft Inc. > 72 Eagle Rock Avenue > First Floor > East Hanover, NJ 07936 > (973) 952-5000 main > (973) 952-5066 direct > (201) 214-6084 mobile > (973) 952-5050 fax > rshah@dynamicsoft.com > www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 05:26:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12254 for ; Thu, 25 Oct 2001 05:26:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA27516 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 05:26:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27012; Thu, 25 Oct 2001 05:12:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26981 for ; Thu, 25 Oct 2001 05:12:07 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12096 for ; Thu, 25 Oct 2001 05:12:01 -0400 (EDT) Received: from lohi.eng.telia.fi (localhost [127.0.0.1]) by lohi.eng.telia.fi (8.12.1/8.12.1/Debian -2) with ESMTP id f9P9C1Sc008188; Thu, 25 Oct 2001 12:12:01 +0300 Received: (from jh@localhost) by harjus.eng.song.fi (8.12.1/8.12.1/Debian -2) id f9P96uvf001445; Thu, 25 Oct 2001 12:06:56 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15319.54832.23613.483594@harjus.eng.song.fi> Date: Thu, 25 Oct 2001 12:06:56 +0300 To: "Miguel A. Garcia" Cc: Rakesh Shah , "SIPWG Mailing List (sip@ietf.org)" , William Marshall Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt In-Reply-To: <3BD7D2BE.D73B63BB@ericsson.com> References: <15319.45386.993016.801025@harjus.eng.song.fi> <3BD7D2BE.D73B63BB@ericsson.com> X-Mailer: VM 6.96 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Miguel A. Garcia writes: > What IETF has to do is to publish standards that are general enough to > have enough support. In this case, the manyfolks draft is already in > use by PacketCable networks, and planned to by used by 3GPP networks. > I think this is enough support to publish this standard. i didn't say that you should not publish it, but that it currently lacks an applicability statement and evaluation of its effects on call setup delay and network resource utilization. > Note that I don't want to discuss why 3GPP has adopted the mechanisms in > manyfolks in this mailing list. i met yesterday a person who works for a big mobile phone/network vendor and when i asked about manyfolks, he said that the 3gpp indeed has adopted it, but that it is not a mandatory part of the spec and that this vendor has no intention to use it in its own products. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 05:48:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12468 for ; Thu, 25 Oct 2001 05:48:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA28432 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 05:48:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25871; Thu, 25 Oct 2001 04:52:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25839 for ; Thu, 25 Oct 2001 04:52:46 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11845 for ; Thu, 25 Oct 2001 04:52:34 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9P8qIj19555; Thu, 25 Oct 2001 10:52:19 +0200 (MEST) Received: from ericsson.com (E0080C7779971.lmf.ericsson.se [131.160.30.9]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9P8qGB13365; Thu, 25 Oct 2001 11:52:17 +0300 (EET DST) Message-ID: <3BD7D2BE.D73B63BB@ericsson.com> Date: Thu, 25 Oct 2001 11:52:14 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Juha Heinanen CC: Rakesh Shah , "SIPWG Mailing List (sip@ietf.org)" , William Marshall Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt References: <15319.45386.993016.801025@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Juha: I must say that I disagree with your words. First of all, the IETF is the standards protocol factory. I don't think you and me have the right to judge whether a protocol will be a success or a failure. Time will judge this aspect. What IETF has to do is to publish standards that are general enough to have enough support. In this case, the manyfolks draft is already in use by PacketCable networks, and planned to by used by 3GPP networks. I think this is enough support to publish this standard. Secondly, I disagree with your interpretation of manyfolks in 3G networks. There has been a lot of discussions in 3GPP that have proved that manyfolks is useful to establish a PDP context before the remote party rings. The use of resource reservation may be applied to the PDP context in 3G, rather than RSVP (like in PacketCable). Note that I don't want to discuss why 3GPP has adopted the mechanisms in manyfolks in this mailing list. I think it is of no use to the SIP community. It has been long discusse in 3GPP meetings, so no way to re-start the discussion here. /Miguel Juha Heinanen wrote: > > as a general comment i have to say that the idea of interleaving an > end-to-end resource reservation mechanism with sip signaling sounds an > overkill that will introduce lots of new complexity, delay, and > processing in the network devices to the call setup process. i thus > wonder if it will ever be deployed in practise in any large scale. > > lets consider cellular calls as an exaple, which is likely to be the > environment, where the reseource problem will be the greatest. there we > don't need any end-to-end reservation protocol, such as rsvp, to check > that the resources are available. the calling party can simply first > try to create a new real time pdp context for the call and if that > succeeds, he knows that local resources are available. when the invite > hits the called cell phone, it too tries first create a new real time > pdp context for this call and if that succeeds, the phone will ring and > an ok will be send back to the calling party. the packets will then be > marked with a diffserv code point indicating that they should use the > real time pdp context. > > some of the details are missing from the above example, but it should > serve to illustrate my point. the question thus remains, do we really > need in real life the complexity of manyfolks-resource? if it is likely > that other solutions might also work and be widely deployed, the i-d > should say so. otherwise readers might get the impression that this is > THE way to implement qos for sip calls. > > may be i missed it, but the i-d should also try to analyze if the > mechanism will scale if every phone call in the world would use it and > how much additional delay will be introduced by it to the call setup > process. > > -- juha > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 05:58:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12553 for ; Thu, 25 Oct 2001 05:57:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA28663 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 05:58:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28279; Thu, 25 Oct 2001 05:41:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28174 for ; Thu, 25 Oct 2001 05:41:19 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12405 for ; Thu, 25 Oct 2001 05:41:08 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9P9esj26194; Thu, 25 Oct 2001 11:40:54 +0200 (MEST) Received: from ericsson.com (E0080C7779971.lmf.ericsson.se [131.160.30.9]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9P9erB15059; Thu, 25 Oct 2001 12:40:53 +0300 (EET DST) Message-ID: <3BD7DE22.765FDF57@ericsson.com> Date: Thu, 25 Oct 2001 12:40:50 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Juha Heinanen CC: Rakesh Shah , "SIPWG Mailing List (sip@ietf.org)" , William Marshall Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt References: <15319.45386.993016.801025@harjus.eng.song.fi> <3BD7D2BE.D73B63BB@ericsson.com> <15319.54832.23613.483594@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > Miguel A. Garcia writes: > > > What IETF has to do is to publish standards that are general enough to > > have enough support. In this case, the manyfolks draft is already in > > use by PacketCable networks, and planned to by used by 3GPP networks. > > I think this is enough support to publish this standard. > > i didn't say that you should not publish it, but that it currently lacks > an applicability statement and evaluation of its effects on call setup > delay and network resource utilization. This sounds like another internet draft on the applicability statement of the manyfolks draft. *If* such a document is needed, I would like to have it separated from the manyfolks standards track document. > > > Note that I don't want to discuss why 3GPP has adopted the mechanisms in > > manyfolks in this mailing list. > > i met yesterday a person who works for a big mobile phone/network vendor > and when i asked about manyfolks, he said that the 3gpp indeed has > adopted it, but that it is not a mandatory part of the spec and that > this vendor has no intention to use it in its own products. > Good luck to that vendor. I can tell you that manyfolks IS mandatory in 3GPP, so if somebody designs a terminal that does not support manyfolks, is not going to be 3GPP compliant. I believe the person you spoke to is miss-informed. /Miguel > -- juha > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 06:04:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12635 for ; Thu, 25 Oct 2001 06:04:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29121 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 06:04:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28574; Thu, 25 Oct 2001 05:52:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28523 for ; Thu, 25 Oct 2001 05:52:08 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12518 for ; Thu, 25 Oct 2001 05:52:01 -0400 (EDT) Received: from lohi.eng.telia.fi (localhost [127.0.0.1]) by lohi.eng.telia.fi (8.12.1/8.12.1/Debian -2) with ESMTP id f9P9q1Sc008241; Thu, 25 Oct 2001 12:52:01 +0300 Received: (from jh@localhost) by harjus.eng.song.fi (8.12.1/8.12.1/Debian -2) id f9P9oqhI001466; Thu, 25 Oct 2001 12:50:52 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15319.57468.58195.17236@harjus.eng.song.fi> Date: Thu, 25 Oct 2001 12:50:52 +0300 To: "Miguel A. Garcia" Cc: Rakesh Shah , "SIPWG Mailing List (sip@ietf.org)" , William Marshall Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt In-Reply-To: <3BD7DE22.765FDF57@ericsson.com> References: <15319.45386.993016.801025@harjus.eng.song.fi> <3BD7D2BE.D73B63BB@ericsson.com> <15319.54832.23613.483594@harjus.eng.song.fi> <3BD7DE22.765FDF57@ericsson.com> X-Mailer: VM 6.96 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Miguel A. Garcia writes: > Good luck to that vendor. I can tell you that manyfolks IS mandatory in 3GPP, so if somebody designs a terminal that does not support manyfolks, is not going to be 3GPP compliant. I believe the person you spoke to is miss-informed. may be the person was misinformed. i thought that he wasn't, because he was giving a talk in an ip qos conference regarding 3g qos. anyway, i as a mobile network user definely don't want to pay for that extra signaling traffic. there better thus be an option to turn manyfolks off in the 3gpp phone. another option of course is that i don't use your protocols at all, but just plain sip. the more i hear what is going on in the 3gpp standars process, the more likely that schenario becomes. looks like there is noone paying the bill involved in the 3gpp process. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 06:53:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13006 for ; Thu, 25 Oct 2001 06:53:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA00216 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 06:53:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29903; Thu, 25 Oct 2001 06:32:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29874 for ; Thu, 25 Oct 2001 06:32:14 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12870 for ; Thu, 25 Oct 2001 06:32:10 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9PAVh304869 for ; Thu, 25 Oct 2001 06:31:43 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4SFDP5>; Thu, 25 Oct 2001 11:31:37 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC341B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Miguel A. Garcia" , "'Juha Heinanen'" Cc: Rakesh Shah , "SIPWG Mailing List (sip@ietf.org)" , William Marshall Subject: RE: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt Date: Thu, 25 Oct 2001 11:31:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 3GPP TS 24.229 defines it as mandatory for the IM CN subsystem. That of course does not stop you using your IP connection provided by GPRS to register with some other SIP server, but for that you will not get a service that integrates well with what the rest of 3GPP is trying to provide. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Juha Heinanen[SMTP:jh@lohi.eng.song.fi] > Sent: 25 October 2001 10:06 > To: Miguel A. Garcia > Cc: Rakesh Shah; SIPWG Mailing List (sip@ietf.org); William Marshall > Subject: Re: [Sip] Last Call - > draft-ietf-sip-manyfolks-resource-02.txt > > Miguel A. Garcia writes: > > > What IETF has to do is to publish standards that are general enough to > > have enough support. In this case, the manyfolks draft is already in > > use by PacketCable networks, and planned to by used by 3GPP networks. > > I think this is enough support to publish this standard. > > i didn't say that you should not publish it, but that it currently lacks > an applicability statement and evaluation of its effects on call setup > delay and network resource utilization. > > > Note that I don't want to discuss why 3GPP has adopted the mechanisms > in > > manyfolks in this mailing list. > > i met yesterday a person who works for a big mobile phone/network vendor > and when i asked about manyfolks, he said that the 3gpp indeed has > adopted it, but that it is not a mandatory part of the spec and that > this vendor has no intention to use it in its own products. > > -- juha > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 09:17:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18330 for ; Thu, 25 Oct 2001 09:17:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05333 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 09:17:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03544; Thu, 25 Oct 2001 08:50:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03514 for ; Thu, 25 Oct 2001 08:50:55 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16971 for ; Thu, 25 Oct 2001 08:50:51 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 6ABF64CE7E for ; Thu, 25 Oct 2001 08:50:52 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA25214; Thu, 25 Oct 2001 08:50:49 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA16491; Thu, 25 Oct 2001 08:50:18 -0400 (EDT) Date: Thu, 25 Oct 2001 08:50:18 -0400 (EDT) Message-Id: <200110251250.IAA16491@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > may be i missed it, but the i-d should also try to analyze if the > mechanism will scale if every phone call in the world would use it and > how much additional delay will be introduced by it to the call setup > process. All of the content needed for such a section is already contained in the introductory and overview sections of the I-D. I see no reason to duplicate it (the draft is already long enough), or to generate another I-D and increase the workload on all of us. The main point is that call blocking happens, and call defects are bad, and carriers need to distinguish them (unless the blocking rate is so low - but companies that built that much spare capacity have gone under). I believe all the other comments have been already addressed by others. Bill Marshall wtm@research.att.com -----original message----- From: Juha Heinanen Date: Thu, 25 Oct 2001 09:29:30 +0300 To: Rakesh Shah Cc: "SIPWG Mailing List (sip@ietf.org)" Subject: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt as a general comment i have to say that the idea of interleaving an end-to-end resource reservation mechanism with sip signaling sounds an overkill that will introduce lots of new complexity, delay, and processing in the network devices to the call setup process. i thus wonder if it will ever be deployed in practise in any large scale. lets consider cellular calls as an exaple, which is likely to be the environment, where the reseource problem will be the greatest. there we don't need any end-to-end reservation protocol, such as rsvp, to check that the resources are available. the calling party can simply first try to create a new real time pdp context for the call and if that succeeds, he knows that local resources are available. when the invite hits the called cell phone, it too tries first create a new real time pdp context for this call and if that succeeds, the phone will ring and an ok will be send back to the calling party. the packets will then be marked with a diffserv code point indicating that they should use the real time pdp context. some of the details are missing from the above example, but it should serve to illustrate my point. the question thus remains, do we really need in real life the complexity of manyfolks-resource? if it is likely that other solutions might also work and be widely deployed, the i-d should say so. otherwise readers might get the impression that this is THE way to implement qos for sip calls. may be i missed it, but the i-d should also try to analyze if the mechanism will scale if every phone call in the world would use it and how much additional delay will be introduced by it to the call setup process. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 10:23:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20131 for ; Thu, 25 Oct 2001 10:23:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07232 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 10:23:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06428; Thu, 25 Oct 2001 10:00:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06394 for ; Thu, 25 Oct 2001 10:00:03 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19651 for ; Thu, 25 Oct 2001 09:59:58 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9PDwKPI027156 for ; Thu, 25 Oct 2001 09:58:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Oct 2001 09:59:33 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" Subject: [Sip] SIP WG - Last Call Weekly Status Update Date: Thu, 25 Oct 2001 09:59:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dear SIP Working Group Members, This Working Group Last Call status is being sent out to keep you up-to-speed. Any questions about this information can be addressed to Rakesh Shah (mailto:rshah@dynamicsoft.com). Drafts in WGLC draft-ietf-sip-100rel-03.txt Draft in limbo. It has finished last call and been updated recently, but no news from ADs. draft-ietf-sip-serverfeatures-05.txt Chairs are working some issues with ADs. WGLC completed. Draft was submitted to IESG, returned for updates and updates were made by authors. draft-ietf-sip-session-timer-08.txt ADs notified of WGLC completion. No response yet. draft-ietf-sip-callerprefs-04.txt Last Call review completed. Waiting for authors' summary. Summary delayed due to bis re-write. draft-ietf-sip-mib-03.txt List discussion is complete, but there has been no activity beyond the assigned reviewers. draft-ietf-sip-manyfolks-resource-02.txt Open discussion announced. (Critical to 3GPP.) draft-ietf-sip-call-auth-02.txt List open discussion announced. (Critical for 3GPP.) draft-ietf-sip-state-02.txt Contacting NITS reviewer. draft-ietf-sip-refer-01.txt Ready for WGLC. Recently split from transfer draft. Updated from -00 to reflect issues decided at IETF-51. Drafts Queued for WGLC draft-ietf-sip-rfc2543bis-04.txt Major reorg started. -05 to SIPWG 15Oct01. -06 to be delivered 29Oct01. -07 to be delivered 15Nov01. Start WGLC on 15Nov01. draft-ietf-sip-privacy-02.txt Will have a -03 issued. -03 will be ready for WGLC. Will generate a lot of debate. (3GPP interest.) draft-johnston-sip-osp-token-01.txt No status. This information is kept up-to-date on the supplemental SIP WG Web site (link below). Links Last Call Calendar - http://www.softarmor.com/sipwg/lastcall/lccalendar.pl Supplemental SIP WG Web site - http://www.softarmor.com/sipwg Regards, Rakesh ______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 (973) 952-5000 main (973) 952-5066 direct (201) 214-6084 mobile (973) 952-5050 fax rshah@dynamicsoft.com www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 10:37:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20523 for ; Thu, 25 Oct 2001 10:37:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07997 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 10:37:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07081; Thu, 25 Oct 2001 10:18:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07052 for ; Thu, 25 Oct 2001 10:18:10 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20083 for ; Thu, 25 Oct 2001 10:18:05 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 16BF41E072 for ; Thu, 25 Oct 2001 10:18:10 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA26335; Thu, 25 Oct 2001 10:18:06 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id KAA19274; Thu, 25 Oct 2001 10:17:34 -0400 (EDT) Date: Thu, 25 Oct 2001 10:17:34 -0400 (EDT) Message-Id: <200110251417.KAA19274@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Miguel wrote: > Manyfolks should clearly state that the SDP returned in the 200 OK for the > INVITE MUST NOT be used to change the "agreed" SDP negotiated in the INVITE, > 183 (and PRACK) process. The SDP in the 200 OK MUST be sent to allow backward > compatibility of middle proxies, but not to change the SDP itself. This principle will be incorporated in the next revision of the draft. The same principle holds for the SDP contained in the COMET, and the SDP contained in the ACK (if necessary). One item we may need to address is what the behavior of the UA should be if the other endpoint does not follow this requirement (the general rule about strict adherence in what you send, generous about what you receive). For example, if a UAC includes SDP in the INVITE, gets SDP back in 183, but then gets a completely different SDP in the 200OK, what error recovery can it take? Anything better than BYE? MUST the UAC examine the SDP in the 200OK in the first place, or is that just a SHOULD? Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 10:48:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20800 for ; Thu, 25 Oct 2001 10:48:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08484 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 10:48:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07777; Thu, 25 Oct 2001 10:31:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07746 for ; Thu, 25 Oct 2001 10:31:29 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20352 for ; Thu, 25 Oct 2001 10:31:21 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9PEVPC26564; Thu, 25 Oct 2001 16:31:25 +0200 (MEST) Received: from ericsson.com (E0080C7779971.lmf.ericsson.se [131.160.30.9]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9PEVOB25630; Thu, 25 Oct 2001 17:31:24 +0300 (EET DST) Message-ID: <3BD82239.10BB7F7A@ericsson.com> Date: Thu, 25 Oct 2001 17:31:21 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt References: <200110251417.KAA19274@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Miguel wrote: > > Manyfolks should clearly state that the SDP returned in the 200 OK for the > > INVITE MUST NOT be used to change the "agreed" SDP negotiated in the INVITE, > > 183 (and PRACK) process. The SDP in the 200 OK MUST be sent to allow backward > > compatibility of middle proxies, but not to change the SDP itself. > > This principle will be incorporated in the next revision of the draft. > The same principle holds for the SDP contained in the COMET, and the > SDP contained in the ACK (if necessary). > > One item we may need to address is what the behavior of the UA should be > if the other endpoint does not follow this requirement (the general rule > about strict adherence in what you send, generous about what you receive). > > For example, if a UAC includes SDP in the INVITE, gets SDP back in 183, > but then gets a completely different SDP in the 200OK, what error recovery > can it take? Anything better than BYE? MUST the UAC examine the SDP > in the 200OK in the first place, or is that just a SHOULD? > If a UA changes the SDP when it is not allowed, it is definitely a protocol violation. Perhaps we don't need to specify the action, the same as we don't specify any other possible violations in the 2543bis. However, if there is some action to do, I would say that the SDP should be ignored in that case, and the call should be established according to the agreed SDP. /Miguel > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 12:10:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22513 for ; Thu, 25 Oct 2001 12:10:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12027 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 12:10:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10520; Thu, 25 Oct 2001 11:45:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10487 for ; Thu, 25 Oct 2001 11:45:09 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21932 for ; Thu, 25 Oct 2001 11:45:02 -0400 (EDT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GLR00FKUQBQVU@firewall.wcom.com> for sip@ietf.org; Thu, 25 Oct 2001 15:43:02 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GLR00201Q7SMK@pmismtp04.wcomnet.com>; Thu, 25 Oct 2001 15:43:01 +0000 (GMT) Received: from hsinnreich ([166.35.226.44]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GLR0019JQ7CJ8@pmismtp04.wcomnet.com>; Thu, 25 Oct 2001 15:40:26 +0000 (GMT) Date: Thu, 25 Oct 2001 10:40:21 -0500 From: Henry Sinnreich Subject: RE: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt In-reply-to: <15319.45386.993016.801025@harjus.eng.song.fi> To: "'Juha Heinanen'" , "'Rakesh Shah'" Cc: "'SIPWG Mailing List'" Message-id: <000601c15d6b$5c3e11a0$2ce223a6@open.wcomnet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Agree 100% with Juha and would like to add that for the more general interdomain model (expired drafts in the SIP http://www.softarmor.com/sipwg/) we showed call flows with SIP and RSVP with up to 40+ messages, too complex, unless they are very expensive video calls with high bandwidth reservations. Phone calls could just do with best effort or DiffServ at the most. I suppose in an emergency, making QoS a precondition makes no sense anyway IMHO. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Juha Heinanen > Sent: Thursday, October 25, 2001 1:30 AM > To: Rakesh Shah > Cc: SIPWG Mailing List (sip@ietf.org) > Subject: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt > > > as a general comment i have to say that the idea of > interleaving an end-to-end resource reservation mechanism > with sip signaling sounds an overkill that will introduce > lots of new complexity, delay, and processing in the network > devices to the call setup process. i thus wonder if it will > ever be deployed in practise in any large scale. > > lets consider cellular calls as an exaple, which is likely to > be the environment, where the reseource problem will be the > greatest. there we don't need any end-to-end reservation > protocol, such as rsvp, to check that the resources are > available. the calling party can simply first try to create > a new real time pdp context for the call and if that > succeeds, he knows that local resources are available. when > the invite hits the called cell phone, it too tries first > create a new real time pdp context for this call and if that > succeeds, the phone will ring and an ok will be send back to > the calling party. the packets will then be marked with a > diffserv code point indicating that they should use the real > time pdp context. > > some of the details are missing from the above example, but > it should serve to illustrate my point. the question thus > remains, do we really need in real life the complexity of > manyfolks-resource? if it is likely that other solutions > might also work and be widely deployed, the i-d should say > so. otherwise readers might get the impression that this is > THE way to implement qos for sip calls. > > may be i missed it, but the i-d should also try to analyze if > the mechanism will scale if every phone call in the world > would use it and how much additional delay will be introduced > by it to the call setup process. > > -- juha > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Oct 25 13:39:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25075 for ; Thu, 25 Oct 2001 13:39:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14949 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 13:39:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14194; Thu, 25 Oct 2001 13:12:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14161 for ; Thu, 25 Oct 2001 13:12:15 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24270 for ; Thu, 25 Oct 2001 13:12:10 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 9F20D4CE11 for ; Thu, 25 Oct 2001 13:12:09 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA29378; Thu, 25 Oct 2001 13:12:06 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id NAA25168; Thu, 25 Oct 2001 13:11:46 -0400 (EDT) Date: Thu, 25 Oct 2001 13:11:46 -0400 (EDT) Message-Id: <200110251711.NAA25168@fish.research.att.com> To: sip@ietf.org Subject: RE: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Henry, No argument that there may be lots of messages. When you add in the DNS querries, ENUM, TCP ACKs, TLS, AAA, etc, it gets even higher. Just a question of what you want to count. The key question is whether it is worth the increase in message count for a different service. Some carriers (e.g. 3G, PacketCable) obviously think it is. And, what good is it to tie up an operator at the Emergency Services Center with no resources for an RTP stream? Even more important in those cases, IMHO. If the tool is available, the carrier can decide. Bill Marshall wtm@research.att.com -----original message----- From: Henry Sinnreich Subject: RE: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt To: "'Juha Heinanen'" , "'Rakesh Shah'" Cc: "'SIPWG Mailing List'" Agree 100% with Juha and would like to add that for the more general interdomain model (expired drafts in the SIP http://www.softarmor.com/sipwg/) we showed call flows with SIP and RSVP with up to 40+ messages, too complex, unless they are very expensive video calls with high bandwidth reservations. Phone calls could just do with best effort or DiffServ at the most. I suppose in an emergency, making QoS a precondition makes no sense anyway IMHO. Henry _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Oct 25 15:50:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28429 for ; Thu, 25 Oct 2001 15:50:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18781 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 15:50:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17981; Thu, 25 Oct 2001 15:23:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17950 for ; Thu, 25 Oct 2001 15:23:13 -0400 (EDT) Received: from maliwan.psu.ac.th (maliwan.psu.ac.th [192.100.77.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28004 for ; Thu, 25 Oct 2001 15:23:05 -0400 (EDT) Received: from oossy (cnrsipclient.coe.psu.ac.th [172.30.2.11]) by maliwan.psu.ac.th (8.11.4/8.11.4) with SMTP id f9PJMh915594; Fri, 26 Oct 2001 02:22:44 +0700 (ICT) Message-ID: <000a01c15d8b$7ee94a60$0b021eac@oossy> From: "Jatupong Arun" To: Cc: Date: Fri, 26 Oct 2001 02:30:25 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C15DC6.2B0C78F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Sip] How Select Encode for media in sdp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C15DC6.2B0C78F0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable what reason for consider select encode for media in sdp to appropriate = each client. regard, oossy ------=_NextPart_000_0007_01C15DC6.2B0C78F0 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
what reason for consider select encode = for media in=20 sdp to appropriate each client.
 
 
regard,
 
oossy
------=_NextPart_000_0007_01C15DC6.2B0C78F0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Oct 25 15:53:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28598 for ; Thu, 25 Oct 2001 15:53:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18806 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 15:53:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18434; Thu, 25 Oct 2001 15:31:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18403 for ; Thu, 25 Oct 2001 15:31:18 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28154 for ; Thu, 25 Oct 2001 15:31:12 -0400 (EDT) Received: from twinkie.cisco.com (twinkie.cisco.com [64.102.17.214]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9PJTxO02729 for ; Thu, 25 Oct 2001 15:29:59 -0400 (EDT) Received: from cisco.com (dhcp-64-102-92-118.cisco.com [64.102.92.118]) by twinkie.cisco.com (Mirapoint) with ESMTP id AAG32580 (AUTH wferrell); Thu, 25 Oct 2001 15:30:45 -0400 (EDT) Message-ID: <3BD8684B.82E2A000@cisco.com> Date: Thu, 25 Oct 2001 15:30:20 -0400 From: Wray Ferrell X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org References: <3BD45D0D.41D60073@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Session Timer - Timeout on Refresh Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Trying again since I got no responses the first time... Hi, Version 0.8 of the draft states: "If no response is received to a refreshing re_INVITE is received before the session expiration, the UA SHOULD send a BYE request to terminate the call. It SHOULD send this BYE slightly before session expiration" The bis-03 draft of SIP states under Reliability for INVITE Requests: "If no response is received after sending seven packet requests, processing continues as if a 481 response was received for that request." So does the SIP Session Timer override the section on reliability for INVITE requests? More specifically if a UA responsible for refreshing does not receive a response to its' re-INVITE what should its' behavior be? Disconnect the session as if receiving a 481 or keep the session alive since the session expiration has not yet been reached? Thanks, Wray _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Oct 25 17:50:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00869 for ; Thu, 25 Oct 2001 17:50:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21794 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 17:50:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21092; Thu, 25 Oct 2001 17:23:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21061 for ; Thu, 25 Oct 2001 17:23:01 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00576 for ; Thu, 25 Oct 2001 17:22:56 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f9PLMgZ25504; Thu, 25 Oct 2001 17:22:42 -0400 (EDT) Reply-To: From: "Brett Tate" To: "sip-ietf \(E-mail\)" Date: Thu, 25 Oct 2001 17:23:39 -0400 Message-ID: <002801c15d9b$521c3960$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Record routing primary and secondary locations Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, At various times on this list people have alluded to the various possibilities to help ensure that a request can traverse a route for an established call-leg even when a proxy is down. Has such functionality been capture in an IETF draft? If so, which one? Otherwise it would be nice to capture a solution within rfc2543bis or another document. Proposal 1) Only send to one location. If it is down, too bad. Wait for it come back up or release the call. This greatly reduces the number of fault tolerant architecture possibilities. I think that this is the only thing documented today. Please correct me if I am wrong. Proposal 2) Bypass a route location if is down. This bad because the sender can potentially bypass an "important" hop for the call or a hop that renders the subsequent hops unreachable. Proposal 3) Only allow it to been done through DNS lookups returning multiple address. This only works for DNS capable products. Are there other problems with this proposal? Proposal 4) Use the maddr as a primary and host as the secondary. Are there problems with this proposal? I think that this was the latest proposal, however it might have been a dream since I couldn't locate the email thread. :( Proposal 5) Create a SIP extension to introduce a new Route parameter that indicates what should happen on failure to reach the appropriate location specified by the Route entry. Cheers, Brett _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Oct 25 18:05:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01117 for ; Thu, 25 Oct 2001 18:05:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22249 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 18:05:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21699; Thu, 25 Oct 2001 17:43:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21675 for ; Thu, 25 Oct 2001 17:43:51 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00809 for ; Thu, 25 Oct 2001 17:43:45 -0400 (EDT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GLS003HE707A6@firewall.wcom.com> for sip@ietf.org; Thu, 25 Oct 2001 21:43:20 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GLS008016ZL7I@pmismtp04.wcomnet.com>; Thu, 25 Oct 2001 21:43:19 +0000 (GMT) Received: from hsinnreich ([166.35.226.44]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GLS003MV6Z9UZ@pmismtp04.wcomnet.com>; Thu, 25 Oct 2001 21:42:48 +0000 (GMT) Date: Thu, 25 Oct 2001 16:42:45 -0500 From: Henry Sinnreich Subject: RE: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt In-reply-to: <200110251711.NAA25168@fish.research.att.com> To: "'William Marshall'" , sip@ietf.org Message-id: <000101c15d9d$fd0c3990$2ce223a6@open.wcomnet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA21676 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Bill, We have done tens of call flow scenarios on paper, but would be interested if there are network measurements to show the total call setup time. Especially in the 3G environment with wireless access bandwidth being a consideration, has someone measured total call setup in some network tests with wireless end points? Network tests for call setup time would be really the best argument. If SIP with RSVP and AAA gives acceptable measured setup times, it would be an incentive to for us to continue with the interdomain I-Ds. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of William Marshall > Sent: Thursday, October 25, 2001 12:12 PM > To: sip@ietf.org > Subject: RE: [Sip] Last Call - > draft-ietf-sip-manyfolks-resource-02.txt > > > Henry, > > No argument that there may be lots of messages. When you add > in the DNS querries, ENUM, TCP ACKs, TLS, AAA, etc, it gets > even higher. Just a question of what you want to count. The > key question is whether it is worth the increase in message > count for a different service. Some carriers (e.g. 3G, PacketCable) > obviously think it is. > > And, what good is it to tie up an operator at the Emergency > Services Center with no resources for an RTP stream? Even > more important in those cases, IMHO. If the tool is > available, the carrier can decide. > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: Henry Sinnreich > Subject: RE: [Sip] Last Call - > draft-ietf-sip-manyfolks-resource-02.txt > To: "'Juha Heinanen'" , > "'Rakesh Shah'" > Cc: "'SIPWG Mailing List'" > > Agree 100% with Juha and would like to add that for the more > general interdomain model (expired drafts in the SIP > http://www.softarmor.com/sipwg/) we showed call flows with > SIP and RSVP with up to 40+ messages, too complex, unless > they are very expensive video calls with high bandwidth > reservations. Phone calls could just do with best effort or > DiffServ at the most. I suppose in an emergency, making QoS a > precondition makes no sense anyway IMHO. > > Henry > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Oct 25 18:43:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01527 for ; Thu, 25 Oct 2001 18:43:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22929 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 18:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22456; Thu, 25 Oct 2001 18:23:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22427 for ; Thu, 25 Oct 2001 18:23:03 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01306 for ; Thu, 25 Oct 2001 18:22:56 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id f9PMMiV04613; Thu, 25 Oct 2001 18:22:45 -0400 (EDT) Message-ID: <3BD890B4.74214311@cs.columbia.edu> Date: Thu, 25 Oct 2001 18:22:44 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "Miguel A. Garcia" , "'Juha Heinanen'" , Rakesh Shah , "SIPWG Mailing List (sip@ietf.org)" , William Marshall Subject: Re: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt References: <475FF955A05DD411980D00508B6D5FB001AC341B@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Drage, Keith (Keith)" wrote: > > 3GPP TS 24.229 defines it as mandatory for the IM CN subsystem. > > That of course does not stop you using your IP connection provided by GPRS > to register with some other SIP server, but for that you will not get a > service that integrates well with what the rest of 3GPP is trying to > provide. What are these extra services? So far, all I hear about 3GPP "providing" is restrictions on what I can and cannot do... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Oct 25 20:18:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02875 for ; Thu, 25 Oct 2001 20:18:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA24922 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 20:18:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24117; Thu, 25 Oct 2001 19:44:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24088 for ; Thu, 25 Oct 2001 19:44:45 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02328 for ; Thu, 25 Oct 2001 19:44:40 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f9PNiM944158; Thu, 25 Oct 2001 19:44:23 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Wray Ferrell'" , Subject: RE: [Sip] Session Timer - Timeout on Refresh Date: Thu, 25 Oct 2001 19:45:21 -0400 Message-ID: <003301c15daf$1cecb760$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BD8684B.82E2A000@cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Version 0.8 of the draft states: > "If no response is received to a refreshing re_INVITE > is received before the session expiration, the UA > SHOULD send a BYE request to terminate the call. > It SHOULD send this BYE slightly before session > expiration" I think it should be "If no 2xx response ...". > > The bis-03 draft of SIP states under Reliability > for INVITE Requests: > "If no response is received after sending seven packet > requests, processing continues as if a 481 response was > received for that request." Would a 408 be more appropriate than a 481? This would allow the UAC to decide the importance of the re-invite. > So does the SIP Session Timer override the section on > reliability for INVITE requests? More specifically if > a UA responsible for refreshing does not receive a > response to its' re-INVITE what should its' behavior > be? Disconnect the session as if receiving a 481 or > keep the session alive since the session expiration > has not yet been reached? I think that the session should stay alive if the re-invite didn't have a new sdp. Allowing the possibility for multiple failures during session refreshing was one of the reasons why the timer draft starts trying to refresh at 1/2 session-expires. If it was a new sdp in the re-invite, releasing the call might be desired to avoid potential sdp fallback confusion. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Oct 25 20:34:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03278 for ; Thu, 25 Oct 2001 20:34:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA25536 for sip-archive@odin.ietf.org; Thu, 25 Oct 2001 20:34:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24859; Thu, 25 Oct 2001 20:16:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24828 for ; Thu, 25 Oct 2001 20:16:52 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02823 for ; Thu, 25 Oct 2001 20:16:46 -0400 (EDT) Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id AAA21358 for ; Fri, 26 Oct 2001 00:16:50 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001102517160515677 ; Thu, 25 Oct 2001 17:16:05 -0700 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Oct 2001 17:15:21 -0700 Message-ID: From: "Padhye, Chinmay" To: "'brett@broadsoft.com'" , "'Wray Ferrell'", sip@ietf.org Subject: RE: [Sip] Session Timer - Timeout on Refresh Date: Thu, 25 Oct 2001 17:18:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, Please see my questions inline starting with [Chinmay]. Regards, Chinmay -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: Thursday, October 25, 2001 4:45 PM To: 'Wray Ferrell'; sip@ietf.org Subject: RE: [Sip] Session Timer - Timeout on Refresh > Version 0.8 of the draft states: > "If no response is received to a refreshing re_INVITE > is received before the session expiration, the UA > SHOULD send a BYE request to terminate the call. > It SHOULD send this BYE slightly before session > expiration" I think it should be "If no 2xx response ...". > > The bis-03 draft of SIP states under Reliability > for INVITE Requests: > "If no response is received after sending seven packet > requests, processing continues as if a 481 response was > received for that request." Would a 408 be more appropriate than a 481? This would allow the UAC to decide the importance of the re-invite. > So does the SIP Session Timer override the section on > reliability for INVITE requests? More specifically if > a UA responsible for refreshing does not receive a > response to its' re-INVITE what should its' behavior > be? Disconnect the session as if receiving a 481 or > keep the session alive since the session expiration > has not yet been reached? I think that the session should stay alive if the re-invite didn't have a new sdp. --- [Chinmay] Consider the above case where an intermediate proxy has also started a session timer for this call. What should the proxies behavior be? a) Should it release the resources for the call because it does not get a 2xx for the re-INVITE? OR b) Should it wait for a BYE from the UAC? Also what happens when the session timer at the proxy expires? --- Allowing the possibility for multiple failures during session refreshing was one of the reasons why the timer draft starts trying to refresh at 1/2 session-expires. --- [Chinmay] I didn't follow your statement. Can you please clarify what you mean by 'Allowing the possibility for multiple failures'? Do we want to let the refresh fail and still keep the call alive?! --- If it was a new sdp in the re-invite, releasing the call might be desired to avoid potential sdp fallback confusion. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 04:40:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25769 for ; Fri, 26 Oct 2001 04:40:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15679 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 04:40:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14900; Fri, 26 Oct 2001 04:18:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14869 for ; Fri, 26 Oct 2001 04:18:43 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25549 for ; Fri, 26 Oct 2001 04:18:39 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Oct 2001 08:18:45 UT Received: from jhornsby ([193.195.52.40]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 26 Oct 2001 09:20:23 +0100 From: "Jo Hornsby" To: "Rakesh Shah" , Subject: RE: [Sip] SIP WG - Last Call Weekly Status Update Date: Fri, 26 Oct 2001 09:18:41 +0100 Message-ID: <000f01c15df6$d272ee50$2834c3c1@eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 26 Oct 2001 08:20:23.0698 (UTC) FILETIME=[0F3BFF20:01C15DF7] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > This Working Group Last Call status is being sent out to keep you > up-to-speed. > > Any questions about this information can be addressed to > Rakesh Shah > (mailto:rshah@dynamicsoft.com). > > Drafts in WGLC [...] > draft-ietf-sip-rfc2543bis-04.txt > Major reorg started. -05 to SIPWG 15Oct01. -06 to be delivered ^^^^^^^ Did I completely miss this somehow? Or is this out of date, or sommat? > 29Oct01. -07 > to be delivered 15Nov01. Start WGLC on 15Nov01. - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 04:45:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25822 for ; Fri, 26 Oct 2001 04:45:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15796 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 04:45:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15079; Fri, 26 Oct 2001 04:23:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14963 for ; Fri, 26 Oct 2001 04:23:18 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25611; Fri, 26 Oct 2001 04:23:15 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9Q8L3PI004192; Fri, 26 Oct 2001 04:21:04 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 04:22:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" , "'sipping@ietf.org'" , "'sip-implementors@cs.columbia.edu'" Date: Fri, 26 Oct 2001 04:22:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, It is with great pleasure that I announce the availability of draft-ietf-sip-rfc2543bis-05. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-05.txt http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-05.ps http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-05.pdf As most of you are aware of, this version represents a substantial rewrite of the specification. As the spec has evolved over time, text was added in here or there, and the spec grew inconsistent and hard to read. The aim of this rewrite was to make vast improvements on both the conciceness and completeness, and the readability, of the specification. This was no small task, and it was clear that we would need help. So, a "bis editor" team was formed. In addition to Henning and myself, we added four new co-authors to the specification: Robert Sparks, Alan Johnston, Jon Peterson, and Gonzalo Camarillo. Dean and Brian assisted in editing and guidance, Rakesh provided project management, and a dynamicsoft technical writer, Jean Mahoney, was brought in to work the text (although her edits will not reflect until -07). I prepared a new structure for the specification, and the team began to busily write. We held conference calls at least once a week throughout September and October, and iterated on the specification five times before the version above was produced. We even went through the immensely painful task of tracking every single MUST/MAY/SHOULD in bis-04 to make sure nothing was lost. The team did a phenomenal job, and was really dedicated to making this happen in a reasonable time frame. Great work, team! If I had to summarize the nature of the change, I would do so in two ways. First, the new spec is "semantically oriented" instead of "syntactically oriented". That is, instead of focusing on the syntax, and descirbing behavior as a side product of headers and methods, the specification focuses on behaviors, and describes the syntax needed for it. For example, we now have sections specifically dedicated to initating a session (you'd think there would be a section on that in a specification called "session initiation protocol"), modifying a session, and terminating a session. There is a section that describes registrar behavior from the receipt of a REGISTER to the sending of a response. As part of this change, the BNF was collected into one place, and put in the end. We also took the time (Brian did most of this work) to convert from implicit to explicit LWS. The headers section has shrunk tremendously, as most of the normative behavior was moved forward to sections that describe the main operations in SIP. The second big change was to add layering to SIP. Most of us who know sip well have recognized its layering, but it is not clear at all from the presentation. Now, there is an explicit transport layer and transaction layer. UA processing is defined as a UA "core" layer that sits ontop of the transaction and transport layers. We have unified transaction processing between proxies and UAs, so that there is a single set of state machines for trnsaction processing in all elements. Doing so required a somewhat radical change in structure; reliability of the 2xx response to INVITE, and the ACK for 2xx, is no longer handled by the transaction layer. Rather, its done in the UA core. There are now provably terminating state machines for all four transaction types - INVITE and non-INVITE client and servers. The transaction machines have been made transport independent by reverting to timers for many transitions, rather than retransmit counts. As part of the effort to improve readability, there is a lot more tutorial material. Included is a badly needed four page SIP overview up front, with increasing details at the front of subsections as you move through the document. We've also structured it to be top down. Details are towards the end of the spec, basics up front. As a shocker to the PSTN community, the term "call leg" has been eradicated from the specification with prejudice. The reason is that we are using call legs for things like subscriptions, which have nothing to do at all with calls. The new term is "dialog". At the direction of the ADs, I have also incorporated draft-ietf-sip-serverfeatures into bis. In a future revision, the reliability of provisional responses (draft-ietf-sip-100rel) will be incorporated as well. For now, there is a placeholder for it to give people a heads up. Another big change was the extraction of SDP processing into a separate document. The offer/answer model was submitted as a personal I-D, which should appear in the archives soon. Until it does, you can grab a copy at: http://www.jdrosen.net/papers/draft-rosenberg-mmusic-sdp-offer-answer-00.txt This has changed little from bis-04. The main change is how hold is done, based on list consensus. I also added discussion of the ptime attribute. THe bulk of the change in the spec itself is the presentation and rewrite. However, there are, of course, some functional changes in the protocol itself. We have tried to capture as much as we could in the changes section for draft-05. However, I am certain that there are things that were lost or added or changed that we missed. Please keep an eye out, and feel free to point things out on the lists. And definitely read that changes section. This draft is not the end of the rewrite; its just the first major milestone. We now need to get extensive reviews made of it, to verify its correctness and its readability. Over the next few weeks, we'll be collecting and integrating those comments and reviews, with the intent of issuing bis-06 in a few weeks time. So, please take a look and send your comments! I and the other co-authors will be monitoring the lists more closely than usual to answer questions (my unusual absence on the list over the past months has been entirely due to working on bis...) Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 05:53:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26241 for ; Fri, 26 Oct 2001 05:52:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA17172 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 05:53:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16560; Fri, 26 Oct 2001 05:24:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16528 for ; Fri, 26 Oct 2001 05:24:28 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26054 for ; Fri, 26 Oct 2001 05:24:22 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9Q9OOj09256; Fri, 26 Oct 2001 11:24:24 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9Q9ONB21983; Fri, 26 Oct 2001 12:24:23 +0300 (EET DST) Message-ID: <3BD92BC4.D31F08F8@lmf.ericsson.se> Date: Fri, 26 Oct 2001 12:24:20 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Here comes the first small comments. 1. The comment in the Via header is still there. Via = ( "Via" | "v" ) HCOLON 1#( sent-protocol sent-by *( SEMI via-params ) [ comment ] ) 2. The definition for outbound proxy still says that ALL outgoing requests are sent there, not only the initial INVITE (and, of course, every other request if the proxy record routes). My question is: has this solution now been agreed on upon the list? There have been discussions about it before, and I am not sure there really was a solution (if it was, I missed it). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 06:31:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26563 for ; Fri, 26 Oct 2001 06:31:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA18324 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 06:31:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17689; Fri, 26 Oct 2001 06:09:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17658 for ; Fri, 26 Oct 2001 06:09:21 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26350 for ; Fri, 26 Oct 2001 06:09:17 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Oct 2001 10:09:23 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 26 Oct 2001 11:11:02 +0100 From: "James Undery" To: "SIP" Date: Fri, 26 Oct 2001 11:11:02 +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.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 26 Oct 2001 10:11:02.0285 (UTC) FILETIME=[8423FBD0:01C15E06] Content-Transfer-Encoding: 7bit Subject: [Sip] Changes in bis-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Whilst welcoming the intent of the re-write, there are some obvious (first read) changes I'd disagree with (and a lot I like). e.g. Section 16.5, step 2 Updating the Request-URI, replacing it is a MUST !! this is a totally unnecessary and contradictory to all the loose routing discussions at the last IETF. In light of the massive changes, can I suggest that a more realistic timetable for the draft going to the IESG is produced to allow a sufficient review. Also on the minor nit side, Section 22, table 2 has Route and Record-Route as optional headers for REGISTER, this contradicts section 10.3 where they are forbidden. James _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 07:32:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27892 for ; Fri, 26 Oct 2001 07:32:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19839 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 07:32:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17850; Fri, 26 Oct 2001 06:21:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17818 for ; Fri, 26 Oct 2001 06:21:02 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26442 for ; Fri, 26 Oct 2001 06:20:57 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9QAKOC12496 for ; Fri, 26 Oct 2001 12:20:25 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QAKOB24329 for ; Fri, 26 Oct 2001 13:20:24 +0300 (EET DST) Message-ID: <3BD938E5.D8EDCD5B@lmf.ericsson.se> Date: Fri, 26 Oct 2001 13:20:21 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] bis-5: Contact-length Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I think there is a spelling error in the new bis, and it occurs in many (most?) message examples. Instead of Content-Length it says Contact-Length... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 08:00:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28888 for ; Fri, 26 Oct 2001 08:00:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20748 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 08:00:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19427; Fri, 26 Oct 2001 07:27:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19395 for ; Fri, 26 Oct 2001 07:27:03 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27646 for ; Fri, 26 Oct 2001 07:26:55 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 04:26:35 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: sip@ietf.org Date: Fri, 26 Oct 2001 04:26:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Handling of duplicate requests with differing request paths. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org What is the "correct" response code for a UAS wishing to reject a duplicate request with differing via path? In other words, the subsequent request belongs to same SIP "dia-leg" [dialog/call-leg :)] and with the same CSeq as a previously received pending request but with different topmost Via header [ie, same To, From, Call-Id, CSeq & request-uri but different topmost Via]. The SIP standard (bis-04 or bis-05) does not seem to address this (that I can find). This situation is simply treated as an different/independent request (which in my mind undesirable especially for subscriptions). For instance, this would be the case where a proxy has forked a INVITE or SUBSCRIBE request and both requests have found their way to the same UAS but via different paths. The UAS will normally want to respond to duplicate requests with different paths with and error and simply process the request received initially. How about: 482 Request Merged? Regards, Robert. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 08:03:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29074 for ; Fri, 26 Oct 2001 08:03:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21056 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 08:03:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19914; Fri, 26 Oct 2001 07:36:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19883 for ; Fri, 26 Oct 2001 07:36:21 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27958 for ; Fri, 26 Oct 2001 07:36:18 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Oct 2001 11:36:23 UT Received: from jhornsby ([193.195.52.40]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 26 Oct 2001 12:38:02 +0100 From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Fri, 26 Oct 2001 12:36:20 +0100 Message-ID: <001601c15e12$6eb236c0$2834c3c1@eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 26 Oct 2001 11:38:02.0562 (UTC) FILETIME=[ABAB0A20:01C15E12] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > What is the "correct" response code for a UAS wishing to reject a > duplicate request with differing via path? 482. > In other words, the subsequent request belongs to same SIP > "dia-leg" [dialog/call-leg :)] and with the same CSeq as > a previously received pending request but with different topmost > Via header [ie, same To, From, Call-Id, CSeq & request-uri but > different topmost Via]. > The SIP standard (bis-04 or bis-05) does not seem to address this > (that I can find). This situation is simply treated as an > different/independent request (which in my mind undesirable > especially for subscriptions). It does seem to be alluded to in step 2 of Section 13.3.1 of bis-05. However, this only appears to be for INVITE requests, which I'd imagine is a mistake. > For instance, this would be the case where a proxy has forked > a INVITE or SUBSCRIBE request and both requests have found their > way to the same UAS but via different paths. The UAS will normally > want to respond to duplicate requests with different paths with > and error and simply process the request received initially. > How about: > > 482 Request Merged? Sounds ideal. - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 08:11:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29430 for ; Fri, 26 Oct 2001 08:11:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21201 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 08:11:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20160; Fri, 26 Oct 2001 07:41:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20063 for ; Fri, 26 Oct 2001 07:41:49 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28152 for ; Fri, 26 Oct 2001 07:41:44 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9QBfij12572; Fri, 26 Oct 2001 13:41:44 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QBfiB27480; Fri, 26 Oct 2001 14:41:44 +0300 (EET DST) Message-ID: <3BD94BEE.D112083@lmf.ericsson.se> Date: Fri, 26 Oct 2001 14:41:34 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Can't you just send whatever response you sent when you first received the request (via the other path)? Regards, Christer Holmberg Ericsson Finland > What is the "correct" response code for a UAS wishing to reject a duplicate > request with differing via path? In other words, the subsequent request > belongs to same SIP "dia-leg" [dialog/call-leg :)] and with the same CSeq as > a previously received pending request but with different topmost Via header > [ie, same To, From, Call-Id, CSeq & request-uri but different topmost Via]. > The SIP standard (bis-04 or bis-05) does not seem to address this (that I > can find). This situation is simply treated as an different/independent > request (which in my mind undesirable especially for subscriptions). > > For instance, this would be the case where a proxy has forked a INVITE or > SUBSCRIBE request and both requests have found their way to the same UAS but > via different paths. The UAS will normally want to respond to duplicate > requests with different paths with and error and simply process the request > received initially. How about: > > 482 Request Merged? > > Regards, > > Robert. > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 08:50:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01458 for ; Fri, 26 Oct 2001 08:49:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22606 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 08:49:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20496; Fri, 26 Oct 2001 07:58:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20465 for ; Fri, 26 Oct 2001 07:58:38 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28783 for ; Fri, 26 Oct 2001 07:58:35 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 04:58:19 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Christer Holmberg'" Cc: sip@ietf.org Subject: RE: [Sip] Handling of duplicate requests with differing request p aths. Date: Fri, 26 Oct 2001 04:58:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer, Like a 200 OK? [which sets up two subscriptions or two active calls] Or a 183 Session Progress (with the resource reservation works) so that now you have two audio ringback streams being sent to the same call. Does ringing on both dialegs mean that two phones are ringing(ie, two incoming call indications) somewhere or you have two responses that says the same phone is ringing. No I don't think that is a good idea. It is the same request - it should be responded to uniquely on one dialeg and the duplicate removed (IMO). Jo is right. In bis-05 they did add text (which I missed) in 13.1.1 to handle the INVITE case but the general request handling text still treats it as a new request. Robert. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, October 26, 2001 12:42 PM > To: Fairlie-Cuninghame, Robert > Cc: sip@ietf.org > Subject: Re: [Sip] Handling of duplicate requests with > differing request > paths. > > > > Hi, > > Can't you just send whatever response you sent when you first received > the request (via the other path)? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > What is the "correct" response code for a UAS wishing to > reject a duplicate > > request with differing via path? In other words, the > subsequent request > > belongs to same SIP "dia-leg" [dialog/call-leg :)] and with > the same CSeq as > > a previously received pending request but with different > topmost Via header > > [ie, same To, From, Call-Id, CSeq & request-uri but > different topmost Via]. > > The SIP standard (bis-04 or bis-05) does not seem to > address this (that I > > can find). This situation is simply treated as an > different/independent > > request (which in my mind undesirable especially for subscriptions). > > > > For instance, this would be the case where a proxy has > forked a INVITE or > > SUBSCRIBE request and both requests have found their way to > the same UAS but > > via different paths. The UAS will normally want to respond > to duplicate > > requests with different paths with and error and simply > process the request > > received initially. How about: > > > > 482 Request Merged? > > > > Regards, > > > > Robert. > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 09:04:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02116 for ; Fri, 26 Oct 2001 09:04:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23372 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 09:04:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21267; Fri, 26 Oct 2001 08:13:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21238 for ; Fri, 26 Oct 2001 08:13:24 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29528 for ; Fri, 26 Oct 2001 08:13:08 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9QCD9j19264; Fri, 26 Oct 2001 14:13:09 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QCD8B28786; Fri, 26 Oct 2001 15:13:08 +0300 (EET DST) Message-ID: <3BD95351.ECD359FB@lmf.ericsson.se> Date: Fri, 26 Oct 2001 15:13:05 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, What if some kind of Via hiding is used, so that the UAS doesn't see that separate routes have been used? The only Via headers included may be common for both routes. Regards, Christer Holmberg Ericsson Finland "Fairlie-Cuninghame, Robert" wrote: > > Hi Christer, > > Like a 200 OK? [which sets up two subscriptions or two active calls] Or a > 183 Session Progress (with the resource reservation works) so that now you > have two audio ringback streams being sent to the same call. Does ringing > on both dialegs mean that two phones are ringing(ie, two incoming call > indications) somewhere or you have two responses that says the same phone is > ringing. > > No I don't think that is a good idea. It is the same request - it should be > responded to uniquely on one dialeg and the duplicate removed (IMO). > > Jo is right. In bis-05 they did add text (which I missed) in 13.1.1 to > handle the INVITE case but the general request handling text still treats it > as a new request. > > Robert. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Friday, October 26, 2001 12:42 PM > > To: Fairlie-Cuninghame, Robert > > Cc: sip@ietf.org > > Subject: Re: [Sip] Handling of duplicate requests with > > differing request > > paths. > > > > > > > > Hi, > > > > Can't you just send whatever response you sent when you first received > > the request (via the other path)? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > What is the "correct" response code for a UAS wishing to > > reject a duplicate > > > request with differing via path? In other words, the > > subsequent request > > > belongs to same SIP "dia-leg" [dialog/call-leg :)] and with > > the same CSeq as > > > a previously received pending request but with different > > topmost Via header > > > [ie, same To, From, Call-Id, CSeq & request-uri but > > different topmost Via]. > > > The SIP standard (bis-04 or bis-05) does not seem to > > address this (that I > > > can find). This situation is simply treated as an > > different/independent > > > request (which in my mind undesirable especially for subscriptions). > > > > > > For instance, this would be the case where a proxy has > > forked a INVITE or > > > SUBSCRIBE request and both requests have found their way to > > the same UAS but > > > via different paths. The UAS will normally want to respond > > to duplicate > > > requests with different paths with and error and simply > > process the request > > > received initially. How about: > > > > > > 482 Request Merged? > > > > > > Regards, > > > > > > Robert. > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 09:59:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02112 for ; Fri, 26 Oct 2001 09:04:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23379 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 09:04:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20984; Fri, 26 Oct 2001 08:02:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20954 for ; Fri, 26 Oct 2001 08:02:35 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29037 for ; Fri, 26 Oct 2001 08:02:31 -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 IAA03887; Fri, 26 Oct 2001 08:02:01 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA11932; Fri, 26 Oct 2001 08:02:02 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Oct 2001 08:02:01 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57C3FE@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Christer Holmberg'" , Jonathan Rosenberg Cc: "'sip@ietf.org'" Subject: RE: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-0 5 Date: Fri, 26 Oct 2001 08:02:00 -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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I've gotten behind in updating the bnf. This is on my list to fix. Brian > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, October 26, 2001 5:24 AM > To: Jonathan Rosenberg > Cc: 'sip@ietf.org' > Subject: Re: [Sip] Introducing the "new bis" - > draft-ietf-sip-rfc2543bis-05 > > > > Hi, > > Here comes the first small comments. > > 1. > > The comment in the Via header is still there. > > Via = ( "Via" | "v" ) HCOLON > 1#( sent-protocol sent-by > *( SEMI via-params ) [ comment ] ) > > > 2. > > The definition for outbound proxy still says that ALL > outgoing requests > are sent there, not only the initial INVITE (and, of course, > every other > request if the proxy record routes). > > My question is: has this solution now been agreed on upon the list? > There have been discussions about it before, and I am not sure there > really was a solution (if it was, I missed it). > > > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 10:01:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03931 for ; Fri, 26 Oct 2001 10:01:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25939 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 10:01:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22333; Fri, 26 Oct 2001 08:43:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22302 for ; Fri, 26 Oct 2001 08:43:04 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01137 for ; Fri, 26 Oct 2001 08:43:00 -0400 (EDT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GLT00H33CMJJL@firewall.wcom.com> for sip@ietf.org; Fri, 26 Oct 2001 12:42:20 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GLT00F01CME9Q@dgismtp03.wcomnet.com>; Fri, 26 Oct 2001 12:42:19 +0000 (GMT) Received: from wcom.com ([166.44.60.208]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GLT00BLSCM2N5@dgismtp03.wcomnet.com>; Fri, 26 Oct 2001 12:42:04 +0000 (GMT) Date: Fri, 26 Oct 2001 07:43:01 -0500 From: Alan Johnston Subject: Re: [Sip] bis-5: Contact-length To: Christer Holmberg Cc: sip@ietf.org Message-id: <3BD95A55.49A88998@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3BD938E5.D8EDCD5B@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Don't you hate the way cut and paste propagates errors :-( This will be fixed. Thanks, Alan Johnston WorldCom Christer Holmberg wrote: > Hi, > > I think there is a spelling error in the new bis, and it occurs in many > (most?) message examples. Instead of Content-Length it says > Contact-Length... > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 10:08:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04172 for ; Fri, 26 Oct 2001 10:08:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26203 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 10:08:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25043; Fri, 26 Oct 2001 09:44:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25011 for ; Fri, 26 Oct 2001 09:44:00 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03331 for ; Fri, 26 Oct 2001 09:43:55 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 06:43:35 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Christer Holmberg'" , Pekka Pessi Cc: sip@ietf.org Subject: RE: [Sip] Handling of duplicate requests with differing request p aths. Date: Fri, 26 Oct 2001 06:43:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer & Pekka, What would actually happen (eg whether the same or different tag is used in responses) would be implementation specific [if a UAS ignored the text that Jo Hornsby pointed out]. It would depend on how a negative result to the algorithm specified in Section 17.2.3 (Matching Requests To Server Transactions) is handled. However, that discussion (for INVITE anyway) is irrelevant because Bis-05 does describe the correct behavior for an INVITE request (ie send 482 response) but it is not specified for non-INVITE requests. Also Via hiding was removed from the SIP spec in bis-02 - so that is the answer to that question. :) Regards, Robert. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, October 26, 2001 2:18 PM > To: Pekka Pessi > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > Subject: Re: [Sip] Handling of duplicate requests with > differing request > p aths. > > > > Hi > > >In message > > Fairlie-Cuninghame, Robert > writes: > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > Does it? Both have identical to-tags. How is the original > > client going to tell difference? It does not have > a benefit of > > branch parameter. > > I agree with Pekka. There are no via headers in the response when the > UAC receives it, and if the To-tags are identical the UAC > will treat the > response as a retransmission of the final response (the UAS > will resend > the final response until it receives the ACK). > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 10:15:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04423 for ; Fri, 26 Oct 2001 10:15:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26433 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 10:15:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23468; Fri, 26 Oct 2001 09:06:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23437 for ; Fri, 26 Oct 2001 09:06:30 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02206 for ; Fri, 26 Oct 2001 09:06:25 -0400 (EDT) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9QD4Zc18924 for ; Fri, 26 Oct 2001 16:04:35 +0300 (EET DST) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Oct 2001 16:06:25 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id V2DDQMDM; Fri, 26 Oct 2001 16:06:25 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id QAA29254; Fri, 26 Oct 2001 16:06:25 +0300 (EETDST) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.2/8.11.2) id f9QD9LE03655; Fri, 26 Oct 2001 16:09:21 +0300 To: Fairlie-Cuninghame@agni.research.nokia.com Cc: Robert , Christer Holmberg , Subject: Re: [Sip] Handling of duplicate requests with differing request p aths. References: X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: Fairlie-Cuninghame, Robert's message of "Fri, 26 Oct 2001 14:58:18 +0300" Date: 26 Oct 2001 16:09:20 +0300 Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In message Fairlie-Cuninghame, Robert writes: >Like a 200 OK? [which sets up two subscriptions or two active calls] Does it? Both have identical to-tags. How is the original client going to tell difference? It does not have a benefit of branch parameter. Pekka _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 10:27:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04935 for ; Fri, 26 Oct 2001 10:27:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26858 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 10:27:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23824; Fri, 26 Oct 2001 09:18:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23793 for ; Fri, 26 Oct 2001 09:18:22 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02551 for ; Fri, 26 Oct 2001 09:18:06 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9QDI4j02976; Fri, 26 Oct 2001 15:18:04 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QDI3B01256; Fri, 26 Oct 2001 16:18:03 +0300 (EET DST) Message-ID: <3BD96288.7980616B@lmf.ericsson.se> Date: Fri, 26 Oct 2001 16:18:00 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Pessi CC: Fairlie-Cuninghame@agni.research.nokia.com, Robert , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request p aths. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi >In message Fairlie-Cuninghame, Robert > writes: >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > Does it? Both have identical to-tags. How is the original > client going to tell difference? It does not have a benefit of > branch parameter. I agree with Pekka. There are no via headers in the response when the UAC receives it, and if the To-tags are identical the UAC will treat the response as a retransmission of the final response (the UAS will resend the final response until it receives the ACK). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Oct 26 10:45:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05692 for ; Fri, 26 Oct 2001 10:45:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28131 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 10:45:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26052; Fri, 26 Oct 2001 10:03:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26021 for ; Fri, 26 Oct 2001 10:03:47 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04014 for ; Fri, 26 Oct 2001 10:03:38 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9QE3Zj24378; Fri, 26 Oct 2001 16:03:35 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QE3YB02515; Fri, 26 Oct 2001 17:03:34 +0300 (EET DST) Message-ID: <3BD96D32.625C6D03@lmf.ericsson.se> Date: Fri, 26 Oct 2001 17:03:30 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: Pekka Pessi , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >Hi Christer & Pekka, > >What would actually happen (eg whether the same or different tag is used in >responses) would be implementation specific [if a UAS ignored the text that >Jo Hornsby pointed out]. It would depend on how a negative result to the >algorithm specified in Section 17.2.3 (Matching Requests To Server >Transactions) is handled. I am not sure I understand how it can be an implementation specific issue. If the UAC receives two (or more) identical 200 OK responses, doesn't it always assume it is a re-transmisson? >However, that discussion (for INVITE anyway) is irrelevant because Bis-05 >does describe the correct behavior for an INVITE request (ie send 482 >response) but it is not specified for non-INVITE requests. > >Also Via hiding was removed from the SIP spec in bis-02 - so that is the >answer to that question. :) I know. I had 3GPP on my mind, but the way it's done there doesn't affect this. Regards, Christer Holmberg Ericsson Finland > > Regards, > > Robert. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Friday, October 26, 2001 2:18 PM > > To: Pekka Pessi > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > > Subject: Re: [Sip] Handling of duplicate requests with > > differing request > > p aths. > > > > > > > > Hi > > > > >In message > > > > Fairlie-Cuninghame, Robert > writes: > > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > > > Does it? Both have identical to-tags. How is the original > > > client going to tell difference? It does not have > > a benefit of > > > branch parameter. > > > > I agree with Pekka. There are no via headers in the response when the > > UAC receives it, and if the To-tags are identical the UAC > > will treat the > > response as a retransmission of the final response (the UAS > > will resend > > the final response until it receives the ACK). > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 10:53:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05976 for ; Fri, 26 Oct 2001 10:53:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28552 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 10:53:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26505; Fri, 26 Oct 2001 10:16:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26476 for ; Fri, 26 Oct 2001 10:16:40 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04479 for ; Fri, 26 Oct 2001 10:16:36 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9QEGMC07674; Fri, 26 Oct 2001 16:16:22 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QEGMB02847; Fri, 26 Oct 2001 17:16:22 +0300 (EET DST) Message-ID: <3BD97032.322AB793@lmf.ericsson.se> Date: Fri, 26 Oct 2001 17:16:18 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: "Fairlie-Cuninghame, Robert" , Pekka Pessi Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <3BD96D32.625C6D03@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Another question related to this: If the UAS receives multiple instances of the INVITE, it may send 200 to the first and then 482 to the others. Now, it also have to receive separate ACKs for all the final responses, so my question is: will the Via branch always be the same in the ACK as it was in the INVITE (or whatever request method), or how does the UAS map the ACK to a specific 482 (or 200)? Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > > Hi, > > >Hi Christer & Pekka, > > > >What would actually happen (eg whether the same or different tag is used in > >responses) would be implementation specific [if a UAS ignored the text that > >Jo Hornsby pointed out]. It would depend on how a negative result to the > >algorithm specified in Section 17.2.3 (Matching Requests To Server > >Transactions) is handled. > > I am not sure I understand how it can be an implementation specific > issue. If the UAC receives two (or more) identical 200 OK responses, > doesn't it always assume it is a re-transmisson? > > >However, that discussion (for INVITE anyway) is irrelevant because Bis-05 > >does describe the correct behavior for an INVITE request (ie send 482 > >response) but it is not specified for non-INVITE requests. > > > >Also Via hiding was removed from the SIP spec in bis-02 - so that is the > >answer to that question. :) > > I know. I had 3GPP on my mind, but the way it's done there doesn't > affect this. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > > > Robert. > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Friday, October 26, 2001 2:18 PM > > > To: Pekka Pessi > > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > > > Subject: Re: [Sip] Handling of duplicate requests with > > > differing request > > > p aths. > > > > > > > > > > > > Hi > > > > > > >In message > > > > > > Fairlie-Cuninghame, Robert > writes: > > > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > > > > > Does it? Both have identical to-tags. How is the original > > > > client going to tell difference? It does not have > > > a benefit of > > > > branch parameter. > > > > > > I agree with Pekka. There are no via headers in the response when the > > > UAC receives it, and if the To-tags are identical the UAC > > > will treat the > > > response as a retransmission of the final response (the UAS > > > will resend > > > the final response until it receives the ACK). > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 11:11:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06447 for ; Fri, 26 Oct 2001 11:11:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29382 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 11:11:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27586; Fri, 26 Oct 2001 10:37:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27559 for ; Fri, 26 Oct 2001 10:37:03 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05431 for ; Fri, 26 Oct 2001 10:36:59 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9QEZCc21938 for ; Fri, 26 Oct 2001 17:35:13 +0300 (EET DST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Oct 2001 17:37:00 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh01nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id VLV0RWVM; Fri, 26 Oct 2001 17:37:00 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA29701; Fri, 26 Oct 2001 17:37:00 +0300 (EETDST) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.2/8.11.2) id f9QEdqr04287; Fri, 26 Oct 2001 17:39:52 +0300 To: Christer Holmberg Cc: , "Fairlie-Cuninghame, Robert" , "Pekka Pessi" Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <3BD97032.322AB793@lmf.ericsson.se> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: Christer Holmberg's message of "Fri, 26 Oct 2001 17:16:18 +0300" Date: 26 Oct 2001 17:39:52 +0300 Message-ID: Lines: 12 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In message <3BD97032.322AB793@lmf.ericsson.se> Christer Holmberg writes: >Now, it also have to receive separate ACKs for all the final responses, >so my question is: will the Via branch always be the same in the ACK as >it was in the INVITE (or whatever request method), or how does the UAS >map the ACK to a specific 482 (or 200)? For the 482, the branch value is always identical. The ACK for 200 may follow different route, so the branch value may be different as well as the requestURI. Section 5.1.1 in bis-04, 13.1 in bis-05. Pekka _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 11:14:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06553 for ; Fri, 26 Oct 2001 11:14:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29461 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 11:14:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27957; Fri, 26 Oct 2001 10:42:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27856 for ; Fri, 26 Oct 2001 10:42:10 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05567 for ; Fri, 26 Oct 2001 10:42:07 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9QEflj28551; Fri, 26 Oct 2001 16:41:47 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QEfkB03391; Fri, 26 Oct 2001 17:41:46 +0300 (EET DST) Message-ID: <3BD97626.DAE274E6@lmf.ericsson.se> Date: Fri, 26 Oct 2001 17:41:42 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: sip@ietf.org, Pekka Pessi Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >Yes the branch-ID must be the same for ACK & CANCEL requests as the original >request (see Section 13.5). Oki. I missed that. My misstake. >>I am not sure I understand how it can be an implementation specific >>issue. If the UAC receives two (or more) identical 200 OK responses, >>doesn't it always assume it is a re-transmission? >A UAS would consider it a retransmission if the function that matches >requests to server transactions (17.2.3) returned a positive match. However, >because the top-most Via is different, the function will not return a match. >As no other behavior for non-INVITE method is defined then what will result >is implementation specific. I am talking about the response, and the UAC behaviour. However, I noticed that it doesn't matter how many identical responses (482, for example) we receive, since we will simply ACK those. I think that clarified my issues :) Thanks! Christer Holmberg Ericsson Finland > > Robert. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Friday, October 26, 2001 3:16 PM > > To: sip@ietf.org > > Cc: Fairlie-Cuninghame, Robert; Pekka Pessi > > Subject: Re: [Sip] Handling of duplicate requests with > > differing request > > paths. > > > > > > > > Hi, > > > > Another question related to this: > > > > If the UAS receives multiple instances of the INVITE, it may > > send 200 to > > the first and then 482 to the others. > > > > Now, it also have to receive separate ACKs for all the final > > responses, > > so my question is: will the Via branch always be the same in > > the ACK as > > it was in the INVITE (or whatever request method), or how does the UAS > > map the ACK to a specific 482 (or 200)? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > >Hi Christer & Pekka, > > > > > > > >What would actually happen (eg whether the same or > > different tag is used in > > > >responses) would be implementation specific [if a UAS > > ignored the text that > > > >Jo Hornsby pointed out]. It would depend on how a negative > > result to the > > > >algorithm specified in Section 17.2.3 (Matching Requests To Server > > > >Transactions) is handled. > > > > > > I am not sure I understand how it can be an implementation specific > > > issue. If the UAC receives two (or more) identical 200 OK responses, > > > doesn't it always assume it is a re-transmisson? > > > > > > >However, that discussion (for INVITE anyway) is irrelevant > > because Bis-05 > > > >does describe the correct behavior for an INVITE request > > (ie send 482 > > > >response) but it is not specified for non-INVITE requests. > > > > > > > >Also Via hiding was removed from the SIP spec in bis-02 - > > so that is the > > > >answer to that question. :) > > > > > > I know. I had 3GPP on my mind, but the way it's done there doesn't > > > affect this. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > Regards, > > > > > > > > Robert. > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Friday, October 26, 2001 2:18 PM > > > > To: Pekka Pessi > > > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > > > > Subject: Re: [Sip] Handling of duplicate requests with > > > > differing request > > > > p aths. > > > > > > > > > > > > > > > > Hi > > > > > > > > >In message > > > > > > > > Fairlie-Cuninghame, Robert > writes: > > > > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > > > > > > > Does it? Both have identical to-tags. How is the original > > > > > client going to tell difference? It does not have > > > > a benefit of > > > > > branch parameter. > > > > > > > > I agree with Pekka. There are no via headers in the response when the > > > > UAC receives it, and if the To-tags are identical the UAC > > > > will treat the > > > > response as a retransmission of the final response (the UAS > > > > will resend > > > > the final response until it receives the ACK). > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 11:19:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06688 for ; Fri, 26 Oct 2001 11:19:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29592 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 11:19:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28177; Fri, 26 Oct 2001 10:45:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28146 for ; Fri, 26 Oct 2001 10:45:26 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05696 for ; Fri, 26 Oct 2001 10:45:16 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9QEj5j00891; Fri, 26 Oct 2001 16:45:05 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QEj4B03426; Fri, 26 Oct 2001 17:45:04 +0300 (EET DST) Message-ID: <3BD976EC.4B73CDC9@lmf.ericsson.se> Date: Fri, 26 Oct 2001 17:45:00 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Pessi CC: sip@ietf.org, "Fairlie-Cuninghame, Robert" Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <3BD97032.322AB793@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >In message <3BD97032.322AB793@lmf.ericsson.se> Christer Holmberg writes: >>Now, it also have to receive separate ACKs for all the final responses, >>so my question is: will the Via branch always be the same in the ACK as >>it was in the INVITE (or whatever request method), or how does the UAS >>map the ACK to a specific 482 (or 200)? > > For the 482, the branch value is always identical. The ACK for > 200 may follow different route, so the branch value may be > different as well as the requestURI. Section 5.1.1 in bis-04, > 13.1 in bis-05. So, if we have sent one 200 OK, and multiple 482, and we receive an ACK with a branch we can't match, we have to assume that it belongs to the 200 OK. That is, of course, true even in a normal case where we only received one instance of the INVITE, and only sent one final response (200 OK). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 11:29:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07129 for ; Fri, 26 Oct 2001 11:29:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29788 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 11:29:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29206; Fri, 26 Oct 2001 11:07:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29175 for ; Fri, 26 Oct 2001 11:07:29 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06345 for ; Fri, 26 Oct 2001 11:07:26 -0400 (EDT) Received: from softarmor.com (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with ESMTP id f9QFDSD01805; Fri, 26 Oct 2001 10:13:28 -0500 Message-ID: <3BD97CF0.5010603@softarmor.com> Date: Fri, 26 Oct 2001 10:10:40 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Rakesh Shah CC: "SIPWG Mailing List (sip@ietf.org)" Subject: Re: [Sip] SIP WG - Last Call Weekly Status Update References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have a wee bit more information. Rakesh Shah wrote: >draft-ietf-sip-100rel-03.txt >Draft in limbo. It has finished last call and been updated recently, but no >news from ADs. > This material is being moved into the SIP core specification >draft-ietf-sip-serverfeatures-05.txt >Chairs are working some issues with ADs. WGLC completed. Draft was submitted >to IESG, returned for updates and updates were made by authors. > We may be moving this material into the core SIP specification. The most recent bis draft also includes SRV. >draft-ietf-sip-rfc2543bis-04.txt >Major reorg started. -05 to SIPWG 15Oct01. -06 to be delivered 29Oct01. -07 >to be delivered 15Nov01. Start WGLC on 15Nov01. > -05 is now available. -06 is expected in several weeks. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 12:14:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06689 for ; Fri, 26 Oct 2001 11:19:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29597 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 11:19:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27639; Fri, 26 Oct 2001 10:37:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27614 for ; Fri, 26 Oct 2001 10:37:25 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05435 for ; Fri, 26 Oct 2001 10:37:21 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 07:37:06 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Christer Holmberg'" , sip@ietf.org Cc: Pekka Pessi Subject: RE: [Sip] Handling of duplicate requests with differing request p aths. Date: Fri, 26 Oct 2001 07:36:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer, Yes the branch-ID must be the same for ACK & CANCEL requests as the original request (see Section 13.5). In answer to you previous email: > > I am not sure I understand how it can be an implementation specific > > issue. If the UAC receives two (or more) identical 200 OK responses, > > doesn't it always assume it is a re-transmission? > > A UAS would consider it a retransmission if the function that matches requests to server transactions (17.2.3) returned a positive match. However, because the top-most Via is different, the function will not return a match. As no other behavior for non-INVITE method is defined then what will result is implementation specific. Robert. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, October 26, 2001 3:16 PM > To: sip@ietf.org > Cc: Fairlie-Cuninghame, Robert; Pekka Pessi > Subject: Re: [Sip] Handling of duplicate requests with > differing request > paths. > > > > Hi, > > Another question related to this: > > If the UAS receives multiple instances of the INVITE, it may > send 200 to > the first and then 482 to the others. > > Now, it also have to receive separate ACKs for all the final > responses, > so my question is: will the Via branch always be the same in > the ACK as > it was in the INVITE (or whatever request method), or how does the UAS > map the ACK to a specific 482 (or 200)? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Christer Holmberg wrote: > > > > Hi, > > > > >Hi Christer & Pekka, > > > > > >What would actually happen (eg whether the same or > different tag is used in > > >responses) would be implementation specific [if a UAS > ignored the text that > > >Jo Hornsby pointed out]. It would depend on how a negative > result to the > > >algorithm specified in Section 17.2.3 (Matching Requests To Server > > >Transactions) is handled. > > > > I am not sure I understand how it can be an implementation specific > > issue. If the UAC receives two (or more) identical 200 OK responses, > > doesn't it always assume it is a re-transmisson? > > > > >However, that discussion (for INVITE anyway) is irrelevant > because Bis-05 > > >does describe the correct behavior for an INVITE request > (ie send 482 > > >response) but it is not specified for non-INVITE requests. > > > > > >Also Via hiding was removed from the SIP spec in bis-02 - > so that is the > > >answer to that question. :) > > > > I know. I had 3GPP on my mind, but the way it's done there doesn't > > affect this. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Regards, > > > > > > Robert. > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Friday, October 26, 2001 2:18 PM > > > To: Pekka Pessi > > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > > > Subject: Re: [Sip] Handling of duplicate requests with > > > differing request > > > p aths. > > > > > > > > > > > > Hi > > > > > > >In message > > > > > > Fairlie-Cuninghame, Robert > writes: > > > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > > > > > Does it? Both have identical to-tags. How is the original > > > > client going to tell difference? It does not have > > > a benefit of > > > > branch parameter. > > > > > > I agree with Pekka. There are no via headers in the response when the > > > UAC receives it, and if the To-tags are identical the UAC > > > will treat the > > > response as a retransmission of the final response (the UAS > > > will resend > > > the final response until it receives the ACK). > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 12:52:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10723 for ; Fri, 26 Oct 2001 12:52:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03187 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 12:52:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01982; Fri, 26 Oct 2001 12:13:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01951 for ; Fri, 26 Oct 2001 12:13:07 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08852 for ; Fri, 26 Oct 2001 12:12:49 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9QGCB012468; Fri, 26 Oct 2001 11:12:11 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9QGCAq13638; Fri, 26 Oct 2001 11:12:10 -0500 (CDT) Received: from lmf.ericsson.se (rmt160179.am.ericsson.se [138.85.160.179]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA11712; Fri, 26 Oct 2001 11:12:07 -0500 (CDT) Message-ID: <3BD9902E.4F65C774@lmf.ericsson.se> Date: Fri, 26 Oct 2001 19:32:46 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: A Venkatraman CC: Christer Holmberg , sip@ietf.org, "Fairlie-Cuninghame, Robert" , Pekka Pessi , Jo Hornsby Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, As it was pointed out, section 13.3.1 indicates that a 482 response has to be generated by the UAS. However, it is true that this should be a general behavior applicable not only to INVITEs but to any method. Furthermore, proxies should follow this behavior as well. We will clarify this. Regards, Gonzalo A Venkatraman wrote: > > Since the 4xx response is ACKed by the proxy, the VIA will have the same > branch. > If it is a 2xx, ACK may be received with a different VIA (ie from the UAC, > if not Record-routed). In this case, the UAS will keep retransmitting the > 200 > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Christer > Holmberg > Sent: Friday, October 26, 2001 9:16 AM > To: sip@ietf.org > Cc: Fairlie-Cuninghame, Robert; Pekka Pessi > Subject: Re: [Sip] Handling of duplicate requests with differing request > paths. > > Hi, > > Another question related to this: > > If the UAS receives multiple instances of the INVITE, it may send 200 to > the first and then 482 to the others. > > Now, it also have to receive separate ACKs for all the final responses, > so my question is: will the Via branch always be the same in the ACK as > it was in the INVITE (or whatever request method), or how does the UAS > map the ACK to a specific 482 (or 200)? > > Regards, > > Christer Holmberg > Ericsson Finland > > Christer Holmberg wrote: > > > > Hi, > > > > >Hi Christer & Pekka, > > > > > >What would actually happen (eg whether the same or different tag is used > in > > >responses) would be implementation specific [if a UAS ignored the text > that > > >Jo Hornsby pointed out]. It would depend on how a negative result to the > > >algorithm specified in Section 17.2.3 (Matching Requests To Server > > >Transactions) is handled. > > > > I am not sure I understand how it can be an implementation specific > > issue. If the UAC receives two (or more) identical 200 OK responses, > > doesn't it always assume it is a re-transmisson? > > > > >However, that discussion (for INVITE anyway) is irrelevant because Bis-05 > > >does describe the correct behavior for an INVITE request (ie send 482 > > >response) but it is not specified for non-INVITE requests. > > > > > >Also Via hiding was removed from the SIP spec in bis-02 - so that is the > > >answer to that question. :) > > > > I know. I had 3GPP on my mind, but the way it's done there doesn't > > affect this. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Regards, > > > > > > Robert. > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Friday, October 26, 2001 2:18 PM > > > > To: Pekka Pessi > > > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > > > > Subject: Re: [Sip] Handling of duplicate requests with > > > > differing request > > > > p aths. > > > > > > > > > > > > > > > > Hi > > > > > > > > >In message > > > > > > > > Fairlie-Cuninghame, Robert > writes: > > > > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > > > > > > > Does it? Both have identical to-tags. How is the original > > > > > client going to tell difference? It does not have > > > > a benefit of > > > > > branch parameter. > > > > > > > > I agree with Pekka. There are no via headers in the response when the > > > > UAC receives it, and if the To-tags are identical the UAC > > > > will treat the > > > > response as a retransmission of the final response (the UAS > > > > will resend > > > > the final response until it receives the ACK). > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 12:54:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10766 for ; Fri, 26 Oct 2001 12:54:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03218 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 12:54:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00723; Fri, 26 Oct 2001 11:55:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00695 for ; Fri, 26 Oct 2001 11:55:19 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08196 for ; Fri, 26 Oct 2001 11:55:15 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9QFrUPI006746; Fri, 26 Oct 2001 11:53:31 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 11:54:42 -0400 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , SIP Subject: RE: [Sip] Changes in bis-05 Date: Fri, 26 Oct 2001 11:54:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Friday, October 26, 2001 6:11 AM > To: SIP > Subject: [Sip] Changes in bis-05 > > > Hi, > > Whilst welcoming the intent of the re-write, there are some obvious > (first read) changes I'd disagree with (and a lot I like). > > e.g. > Section 16.5, step 2 Updating the Request-URI, replacing it is a MUST > !! this is a totally unnecessary and contradictory to all the loose > routing discussions at the last IETF. > Well, its not different from how its always been. This text is not a statement of a decision, just a no-change from previous versions. I believe this issue to be the largest open issue at the moment in the spec, and I believe its even called out in bis-05. > In light of the massive changes, can I suggest that a more realistic > timetable for the draft going to the IESG is produced to allow a > sufficient review. Dean and Brian need to address that one. > > Also on the minor nit side, > > Section 22, table 2 has Route and Record-Route as optional headers for > REGISTER, this contradicts section 10.3 where they are forbidden. OK, thanks. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 12:54:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10762 for ; Fri, 26 Oct 2001 12:54:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03222 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 12:54:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28412; Fri, 26 Oct 2001 10:49:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28350 for ; Fri, 26 Oct 2001 10:49:39 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05799 for ; Fri, 26 Oct 2001 10:49:35 -0400 (EDT) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9QEn3U13690; Fri, 26 Oct 2001 07:49:03 -0700 (PDT) Received: from arunvenkw2k (dhcp-64-101-150-140.cisco.com [64.101.150.140]) by sponge.cisco.com (Mirapoint) with SMTP id AAU11768; Fri, 26 Oct 2001 09:46:18 -0500 (CDT) From: "A Venkatraman" To: "Christer Holmberg" , Cc: "Fairlie-Cuninghame, Robert" , "Pekka Pessi" Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Fri, 26 Oct 2001 09:53:20 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3BD97032.322AB793@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Since the 4xx response is ACKed by the proxy, the VIA will have the same branch. If it is a 2xx, ACK may be received with a different VIA (ie from the UAC, if not Record-routed). In this case, the UAS will keep retransmitting the 200 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Christer Holmberg Sent: Friday, October 26, 2001 9:16 AM To: sip@ietf.org Cc: Fairlie-Cuninghame, Robert; Pekka Pessi Subject: Re: [Sip] Handling of duplicate requests with differing request paths. Hi, Another question related to this: If the UAS receives multiple instances of the INVITE, it may send 200 to the first and then 482 to the others. Now, it also have to receive separate ACKs for all the final responses, so my question is: will the Via branch always be the same in the ACK as it was in the INVITE (or whatever request method), or how does the UAS map the ACK to a specific 482 (or 200)? Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > > Hi, > > >Hi Christer & Pekka, > > > >What would actually happen (eg whether the same or different tag is used in > >responses) would be implementation specific [if a UAS ignored the text that > >Jo Hornsby pointed out]. It would depend on how a negative result to the > >algorithm specified in Section 17.2.3 (Matching Requests To Server > >Transactions) is handled. > > I am not sure I understand how it can be an implementation specific > issue. If the UAC receives two (or more) identical 200 OK responses, > doesn't it always assume it is a re-transmisson? > > >However, that discussion (for INVITE anyway) is irrelevant because Bis-05 > >does describe the correct behavior for an INVITE request (ie send 482 > >response) but it is not specified for non-INVITE requests. > > > >Also Via hiding was removed from the SIP spec in bis-02 - so that is the > >answer to that question. :) > > I know. I had 3GPP on my mind, but the way it's done there doesn't > affect this. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > > > Robert. > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Friday, October 26, 2001 2:18 PM > > > To: Pekka Pessi > > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > > > Subject: Re: [Sip] Handling of duplicate requests with > > > differing request > > > p aths. > > > > > > > > > > > > Hi > > > > > > >In message > > > > > > Fairlie-Cuninghame, Robert > writes: > > > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > > > > > Does it? Both have identical to-tags. How is the original > > > > client going to tell difference? It does not have > > > a benefit of > > > > branch parameter. > > > > > > I agree with Pekka. There are no via headers in the response when the > > > UAC receives it, and if the To-tags are identical the UAC > > > will treat the > > > response as a retransmission of the final response (the UAS > > > will resend > > > the final response until it receives the ACK). > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 13:50:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12833 for ; Fri, 26 Oct 2001 13:50:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05041 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 13:49:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03305; Fri, 26 Oct 2001 12:55:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03272 for ; Fri, 26 Oct 2001 12:55:30 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10880 for ; Fri, 26 Oct 2001 12:55:28 -0400 (EDT) Received: from twinkie.cisco.com (twinkie.cisco.com [64.102.17.214]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9QGsBO23057; Fri, 26 Oct 2001 12:54:12 -0400 (EDT) Received: from cisco.com (dhcp-64-102-92-118.cisco.com [64.102.92.118]) by twinkie.cisco.com (Mirapoint) with ESMTP id AAH04863 (AUTH wferrell); Fri, 26 Oct 2001 12:54:57 -0400 (EDT) Message-ID: <3BD99545.D75E8436@cisco.com> Date: Fri, 26 Oct 2001 12:54:30 -0400 From: Wray Ferrell X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Padhye, Chinmay" CC: "'brett@broadsoft.com'" , sip@ietf.org Subject: Re: [Sip] Session Timer - Timeout on Refresh References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I think that the session should stay alive > if the re-invite didn't have a new sdp. Brett, can you clarify why the difference in behavior if the sdp is updated? Are you saying that the code should treat a change in the sdp as a new session? i.e. a re-INVITE without a sdp change is still the old session in which both sides agreed to keep up for x seconds, but a sdp change is a new session and the agreement reached about the old session no longer matters? > Allowing the possibility for multiple > failures during session refreshing was > one of the reasons why the timer draft > starts trying to refresh at 1/2 > session-expires. > > --- > [Chinmay] > I didn't follow your statement. > > Can you please clarify what you mean by 'Allowing the possibility for > multiple failures'? Not to speak for Brett, but I think what he means is that sending the refresh at 1/2 session-expires allows all the re-tries (unless the SE value is really small) to occur before the session expires. If the refresh was sent near the end of the interval then a temporary network glitch could cause the call to be terminated since the non refreshing UA timer would expire before the refreshing UA had exhausted its' retries. Wray _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 13:59:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13268 for ; Fri, 26 Oct 2001 13:59:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05215 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 13:59:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03387; Fri, 26 Oct 2001 13:00:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03345 for ; Fri, 26 Oct 2001 12:59:58 -0400 (EDT) Received: from imo-m10.mx.aol.com (imo-m10.mx.aol.com [64.12.136.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10995 for ; Fri, 26 Oct 2001 12:59:55 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m10.mx.aol.com (mail_out_v31_r1.8.) id r.135.3a36428 (4216); Fri, 26 Oct 2001 12:59:16 -0400 (EDT) Message-ID: <135.3a36428.290af063@aol.com> Date: Fri, 26 Oct 2001 12:59:15 EDT Subject: Re: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05 To: jdrosen@dynamicsoft.com, sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 112 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, Regarding priority: In Section 26, BNF, (Page 185) the format for Priority got mixed up. Some extra spaces were inserted. We have to figure what these defined values mean for the actual usage. The question is: Why was the list of priorities taken from RFC 2076 rather than from RFC 791? RFC 2076 was informational and copied the list from RFC 1327 (which was obsoleted by RFC 2156), They addressed mapping between X.400 and RFC 822, but RFC 822 did not mention any such values. RFC 791 (and appropriate existing telephony standards) should form the basis of the priority definition field in SIP. At this point, since I presume that no one would agree to deleting the current values in RFC 2543, tokens should be added to correspond to the 5 values defined in RFC 791 (and also in current telephony standards such as ITU-T Q.735) which are required for military networks. The alternative, as I detailed in a previous e-mail, is to add 5 new generic values like "LEVEL0", "LEVEL1", "LEVEL 2", etc. and let networks or countries associate whatever words with these levels that they want. Also, there needs to be an explicit statement concerning the order of the present and the new values. There is no order specified for the current set. Different people would come to different conclusions about the relative order of "Routine" and "non-urgent". It needs to state that the current four values are in the descending order "emergency, urgent, routine, and non-urgent". The order of the 5 new values is as defined in RFC 791 and applicable standards. Also, there should be no defined relation between the current set and the new added set. It is not expected that they would be used together, but if they are, it is a local issue on how to handle them. Mike Pierce Artel _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 14:07:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13607 for ; Fri, 26 Oct 2001 14:07:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05877 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 14:07:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04131; Fri, 26 Oct 2001 13:23:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04100 for ; Fri, 26 Oct 2001 13:23:48 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11712 for ; Fri, 26 Oct 2001 13:23:45 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9QHM3PI007617; Fri, 26 Oct 2001 13:22:03 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 13:23:15 -0400 Message-ID: From: Rakesh Shah To: "'Jo Hornsby'" , sip@ietf.org Subject: RE: [Sip] SIP WG - Last Call Weekly Status Update Date: Fri, 26 Oct 2001 13:23:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org An updating error on my side. I have pulled those dates. New dates are being worked out. Rakesh -----Original Message----- From: Jo Hornsby [mailto:jhornsby@ubiquity.net] Sent: Friday, October 26, 2001 4:19 AM To: Rakesh Shah; sip@ietf.org Subject: RE: [Sip] SIP WG - Last Call Weekly Status Update > This Working Group Last Call status is being sent out to keep you > up-to-speed. > > Any questions about this information can be addressed to > Rakesh Shah > (mailto:rshah@dynamicsoft.com). > > Drafts in WGLC [...] > draft-ietf-sip-rfc2543bis-04.txt > Major reorg started. -05 to SIPWG 15Oct01. -06 to be delivered ^^^^^^^ Did I completely miss this somehow? Or is this out of date, or sommat? > 29Oct01. -07 > to be delivered 15Nov01. Start WGLC on 15Nov01. - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 15:22:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16699 for ; Fri, 26 Oct 2001 15:22:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08919 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 15:22:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07367; Fri, 26 Oct 2001 14:42:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07333 for ; Fri, 26 Oct 2001 14:42:32 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14894 for ; Fri, 26 Oct 2001 14:42:28 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f9QIg7n81977; Fri, 26 Oct 2001 14:42:08 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Session Timer - Timeout on Refresh Date: Fri, 26 Oct 2001 14:43:10 -0400 Message-ID: <003d01c15e4e$0fd06460$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > Version 0.8 of the draft states: > > "If no response is received to a refreshing re_INVITE > > is received before the session expiration, the UA > > SHOULD send a BYE request to terminate the call. > > It SHOULD send this BYE slightly before session > > expiration" > > I think it should be "If no 2xx response ...". > > > > > The bis-03 draft of SIP states under Reliability > > for INVITE Requests: > > "If no response is received after sending seven packet > > requests, processing continues as if a 481 response was > > received for that request." > > Would a 408 be more appropriate than a 481? > This would allow the UAC to decide the > importance of the re-invite. > > > So does the SIP Session Timer override the section on > > reliability for INVITE requests? More specifically if > > a UA responsible for refreshing does not receive a > > response to its' re-INVITE what should its' behavior > > be? Disconnect the session as if receiving a 481 or > > keep the session alive since the session expiration > > has not yet been reached? > > I think that the session should stay alive > if the re-invite didn't have a new sdp. > > --- > [Chinmay] > Consider the above case where an intermediate proxy has also started a > session timer for this call. > > What should the proxies behavior be? > > a) Should it release the resources for the > call because it does not get a > 2xx for the re-INVITE? OR > b) Should it wait for a BYE from the UAC? It should release resources when the session expires. There is no need to wait for the BYE. > Also what happens when the session timer > at the proxy expires? It can cleanup call state and send CANCELs and 4xx's when appropriate. > --- > > Allowing the possibility for multiple > failures during session refreshing was > one of the reasons why the timer draft > starts trying to refresh at 1/2 > session-expires. > > --- > [Chinmay] > I didn't follow your statement. > > Can you please clarify what you mean by > 'Allowing the possibility for > multiple failures'? First refresh failed with 407 from proxy 1. Second failed with a 503 because proxy 2 too busy to process the request. Third failure because proxy 2 was down and proxy 1 returns a 408. Fourth try fails because UAS returns 401. Fifth try is successful. > Do we want to let the refresh fail and > still keep the call alive?! Some refresh request can fail (assuming no 481). A subsequent refresh request can still be successful when sent within the session-expires interval. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 15:23:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16772 for ; Fri, 26 Oct 2001 15:23:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09005 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 15:23:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07260; Fri, 26 Oct 2001 14:39:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29224 for ; Fri, 26 Oct 2001 11:08:22 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06349 for ; Fri, 26 Oct 2001 11:08:19 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 15FB84CE12 for ; Fri, 26 Oct 2001 11:08:22 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA17208; Fri, 26 Oct 2001 11:08:19 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id LAA74159; Fri, 26 Oct 2001 11:08:08 -0400 (EDT) Date: Fri, 26 Oct 2001 11:08:08 -0400 (EDT) Message-Id: <200110261508.LAA74159@fish.research.att.com> To: sip:ietf.org@research.att.com Subject: RE: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org After another careful reading, I have one of my own last call comments to make on this draft. in section 11.3 (Behavior of Destination) 7th paragraph states "When procesing of all preconditions is complete, if a precondition in the initial INVITE specified a confirmation request, the UAS MUST send a COMET message to the UAC ..." This should be changed to "a precondition in the SDP specified ..." in order to cover both the offer SDP contained in the initial INVITE and (when an offer SDP was sent by the UAS in the 183) the answer SDP contained in the PRACK. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 15:55:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17739 for ; Fri, 26 Oct 2001 15:55:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10085 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 15:55:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08982; Fri, 26 Oct 2001 15:22:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08951 for ; Fri, 26 Oct 2001 15:22:57 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16728 for ; Fri, 26 Oct 2001 15:22:53 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id f9QJMVt89322; Fri, 26 Oct 2001 15:22:31 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Wray Ferrell'" Cc: Subject: RE: [Sip] Session Timer - Timeout on Refresh Date: Fri, 26 Oct 2001 15:23:34 -0400 Message-ID: <004001c15e53$b4f7f4d0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BD99545.D75E8436@cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > I think that the session should stay alive > > if the re-invite didn't have a new sdp. > > Brett, can you clarify why the difference in > behavior if the sdp is updated? If a re-invite was only to extend the session, a proxy being down for a minute ultimately shouldn't have a negative impact on the call or call-leg. The UAC can retry again later if time is still available within the session-expires window. However if the re-invite was attempting to change the session by supplying a new SDP, a non-acknowledged re-invite may or may not have been received and/or accepted by the UAS. Thus it can lead to media/SDP confusion. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 16:10:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18131 for ; Fri, 26 Oct 2001 16:10:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11135 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 16:10:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09856; Fri, 26 Oct 2001 15:46:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09828 for ; Fri, 26 Oct 2001 15:46:35 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17546 for ; Fri, 26 Oct 2001 15:46:31 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9QJkKI06818; Fri, 26 Oct 2001 15:46:20 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA12968; Fri, 26 Oct 2001 14:46:19 -0500 (CDT) Message-ID: <3BD9BD5B.B7AC1CB@lucent.com> Date: Fri, 26 Oct 2001 14:45:31 -0500 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , SIP LIST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Folks, > > It is with great pleasure that I announce the availability of > draft-ietf-sip-rfc2543bis-05. Until it appears in the archives, you can > pick it up at: [...] Jonathan: 2 issues with -05 bis: First, since I am updating our proxy to include the new R-R "magic" described in -04 bis, the first thing I did was to note the sections of -05 bis dealing with the R-R "magic". The sections in -05 bis appear to be incomplete wrt to the R-R "magic". Second, the routing procedures outlined in section 16.4 for proxies with Route headers appear to missing some processing that was present in -04 bis. The new routing procedures for proxies processing requests with Route header may NOT work. First, here's what I think is missing from the R-R "magic", along with a suggestion to make it complete. (1) Section 16.6, "Response processing", step 7, first paragraph: the bis mentions that "... the proxy MAY choose to rewrite this value before forwarding the response." but (as far as I can make out) provides no guidance on how to rewrite this value. Note that Section 16.5 provides guidance on how to use Contact (or From) + a transaction identifier in a R-R header when it is being *inserted* in a request. At the very least, section 16.6, "Response processing", step 7, first paragraph can provide some information on how to rewrite the value in an R-R response as follows: "If the selected response contained a Record-Route header field originally inserted by this proxy, AND the proxy had modified the request-URI when inserting the Record-Route, it MUST substitue this value with the Request-URI of the initial request, maintaining the maddr field and port field, before forwarding the response." This ensures that when the R-R response makes it to the UAC, and it creates a Route set, subsequent requests from the UAC will go towards the same downstream direction the original request did. (2) Provide an example, much as -04 bis did. I think that R-R rules for re-writing R-URIs are complex enough that an example will go a long way to ensure clarity, which will aid in interoperability. Now regarding proxy routing procedures, section 16.4 says that if a Route header is present, proxies must use this and follow steps outlined in section 16.5 for further processing this request. Section 16.5, step 8 refers implementors to section 24 to compute an ordered set of addresses from the R-URI and send the request downstream. Problem occurs when a UAC without DNS capabilities has successfully established a session using an outbound proxy which R-R'ed. In this case, subsequent requests arriving at the outbound proxy have the same R-URI and topmost Route (since according to rules in section 12.2.1.1, a DNS-incapable UAC does NOT strip the topmot Route, but DOES use it as the R-URI for the new request) In order to see the problem, consider a proxy for domain example.com which received the following re-INVITE from its DNS-incapable UAC: INVITE sip:salesrep@fiction.com;maddr=proxy.example.com SIP/2.0 Route: Route: The proxy strips the topmost Route header, uses it as the R-URI (leaving only 1 Route header in the request) and following Section 24, ends up sending the request to *it'self*, without stripping maddr. If the maddr is NOT stripped, during the second iteration, the proxy will attempt to route the request to a private address, which may not have any significance outside of the fiction.com domain. -04bis had it right; the proxy should really examine maddr, and if it is one of the interfaces that the proxy is listening on, strip it and route based on the remaining R-URI. This makes the request end up at the proxy for fiction.com domain, which eventually routes it to the private network address 10.2.3.44. Section 16.4, second paragraph can probably be modified to reflect the behavior of stripping maddr if it is one of the interfaces the proxy was listening on. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 17:10:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19172 for ; Fri, 26 Oct 2001 17:10:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12910 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 17:10:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11873; Fri, 26 Oct 2001 16:36:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11841 for ; Fri, 26 Oct 2001 16:36:14 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18572 for ; Fri, 26 Oct 2001 16:36:10 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9QKYtO07116; Fri, 26 Oct 2001 16:34:55 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAC65725 (AUTH pkyzivat); Fri, 26 Oct 2001 16:37:03 -0400 (EDT) Message-ID: <3BD9C8A0.2B1EECCC@cisco.com> Date: Fri, 26 Oct 2001 16:33:36 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Comment on draft-ietf-sip-rfc2543bis-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I haven't read the whole draft yet, but I did read draft-rosenberg-mmusic-sdp-offer-answer-00, and found something there that needs to be addressed in the bis. I just want to post it before I forget. You have now introduced the notion of an offer and an answer, that get mapped onto SDP via draft-rosenberg-mmusic-sdp-offer-answer-00. However in splitting the documents I think you have introduced a subtle change. This has to do with how to determine if the INVITE contains an offer. Bis-04, section 5.1, says "The caller MAY choose to omit the request body (i.e., not send a session description) OR SEND A SESSION DESCRIPTION THAT DOES NOT LIST ANY MEDIA TYPES. This indicates that the caller does not know its desired media characteristics until the call has been accepted." When I read this in the past I concluded that it meant it is permissible to send an SDP body containing a description without any m lines, and this should not be considered to be an offer. Now bis-05 (based on a quick search) no longer says this. In section 13.2.1 it says "The first, ... is that the INVITE contains the offer. ... A second model is that the INVITE contains no session description, the 2xx response contains the offer, and the ACK contains the answer." This no longer permits an SDP body without m lines, that isn't an offer. (Not surprising, because it would be difficult to describe this situation without getting into the details of SDP.) Personally, I think this change is a considerable *improvement*, and I am happy to see it made. But it *is* a change, and probably ought to be discussed, if it hasn't been already. Paul Kyzivat _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Oct 26 18:34:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20208 for ; Fri, 26 Oct 2001 18:34:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14676 for sip-archive@odin.ietf.org; Fri, 26 Oct 2001 18:34:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14066; Fri, 26 Oct 2001 18:01:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14035 for ; Fri, 26 Oct 2001 18:01:27 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19887 for ; Fri, 26 Oct 2001 18:01:23 -0400 (EDT) From: John.Hearty@level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA00804 for ; Fri, 26 Oct 2001 22:01:21 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA22974 for ; Fri, 26 Oct 2001 22:01:21 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <4GXRK1J7>; Fri, 26 Oct 2001 16:01:21 -0600 Message-ID: <17052388D394D411803900508BDFFAF601B36FAE@n0214idc1.oss.level3.com> To: sip@ietf.org Date: Fri, 26 Oct 2001 16:01:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Title your bis-05 comments appropriately Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I suspect there will be lots of comments on this draft. To help all of us follow the threads, please give your comments a subject line appropriate for the comments. I'd hate to see several different threads with the subject 'Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05'. Thanks in advance. John Hearty Level3 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Oct 28 11:05:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14336 for ; Sun, 28 Oct 2001 11:05:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20928 for sip-archive@odin.ietf.org; Sun, 28 Oct 2001 11:05:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19581; Sun, 28 Oct 2001 09:50:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19550 for ; Sun, 28 Oct 2001 09:50:25 -0500 (EST) Received: from nt-mail.tlv.radvision.com ([212.143.185.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13715 for ; Sun, 28 Oct 2001 09:50:23 -0500 (EST) Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id <4115GBKD>; Sun, 28 Oct 2001 16:50:01 +0200 Message-ID: From: Itamar Gilad To: "'Jonathan Rosenberg'" , Itamar Gilad , "'SIP list'" Subject: RE: [Sip] Possible interop issues due to BNF of digest auth Date: Sun, 28 Oct 2001 16:49:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for the response. Shouldn't we have this documented in the spec just to avoid confusion? > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sun, October 21, 2001 11:59 PM > To: 'Itamar Gilad'; 'SIP list' > Subject: RE: [Sip] Possible interop issues due to BNF of digest auth > > > > > > > > -----Original Message----- > > From: Itamar Gilad [mailto:ItamarG@radvision.com] > > Sent: Thursday, October 18, 2001 12:40 PM > > To: 'SIP list' > > Subject: [Sip] Possible interop issues due to BNF of digest auth > > > > > > SIP borrows the definitions of authentication headers from > > RFC 2616 and RFC > > 2617 > > > > RFC 2616 14.47: > > WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge > > > > RFC 2616 14.33: > > Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge > > > > From RFC 2617 3.2.1 as follows: > > > > challenge = "Digest" digest-challenge > > > > digest-challenge = 1#( realm | [ domain ] | nonce | > > [ opaque ] |[ stale ] | [ algorithm ] | > > [ qop-options ] | [auth-param] ) > > > > This means that there's a great deal of freedom in the way > > WWW-Authenticate > > and Proxy-Authenticate headers are constructed which may > lead to major > > interop issues. We've seen some of this in the last SipIt. > > For example the > > header below is valid: > > > > WWW-Authenticate: Digest realm="realm1", realm="realm2", > > nonce="aaaaaEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", > > nonce="rrrrrEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", > > opaque="bbbbbbFiYTAwMzgzYTY4MA==", stale=false, > > algorithm=md5, algorithm=sha1, qop="auth, auth-int", > > Digest realm="realm3", realm="realm4", > > nonce="aaaaaEF1ZyAxNCAxNTowNjoxNyBCU1QgMjAwMVtCQDZkMzJjNAaa", > > opaque="ttttttFiYTAwMzgzYTY4MA==", stale=false, > > algorithm=sha1, qop="auth, > > auth-int" > > No, this is not valid. It passes the grammar, but grammars > are ill suited at > expressing more complex constraints. In this case, the > grammar does not > specify that duplicates of certain parameters are not > allowed. However, I > think it is reasonably clear from the specifications that you > can only have > one realm, one nonce, and so on. Most web browsers have > gotten this right, I > think SIP implementors can too. > > As an example of this, consider the Date header. Dates > introduce constraints > that are far too complex to place in the grammar (for > example, Feburary 29 > is allowed in some years), and it is unrealistic to even try. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 02:43:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06872 for ; Mon, 29 Oct 2001 02:43:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA13001 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 02:43:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11842; Mon, 29 Oct 2001 01:34:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11813 for ; Mon, 29 Oct 2001 01:34:03 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25019 for ; Mon, 29 Oct 2001 01:34:01 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9T6VePI014856; Mon, 29 Oct 2001 01:31:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Oct 2001 01:32:55 -0500 Message-ID: From: Jonathan Rosenberg To: "'John.Hearty@Level3.com'" , sip@ietf.org Subject: RE: [Sip] Title your bis-05 comments appropriately Date: Mon, 29 Oct 2001 01:32:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Right; also, its helpful if you can reference line numbers from the PDF and PS versions (they are identical). -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > Sent: Friday, October 26, 2001 6:01 PM > To: sip@ietf.org > Subject: [Sip] Title your bis-05 comments appropriately > > > > Folks, I suspect there will be lots of comments on this > draft. To help all > of us follow the threads, please give your comments a subject line > appropriate for the comments. I'd hate to see several > different threads > with the subject 'Introducing the "new bis" - > draft-ietf-sip-rfc2543bis-05'. Thanks in advance. > > John Hearty > Level3 > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 03:05:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07102 for ; Mon, 29 Oct 2001 03:05:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA13567 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 03:05:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12409; Mon, 29 Oct 2001 02:05:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12380 for ; Mon, 29 Oct 2001 02:05:32 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05566 for ; Mon, 29 Oct 2001 02:05:29 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9T75Ej25092; Mon, 29 Oct 2001 08:05:15 +0100 (MET) Received: from lmf.ericsson.se (lmf03382pc.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9T75DB21017; Mon, 29 Oct 2001 09:05:13 +0200 (EET) Message-ID: <3BDCFFA7.49815318@lmf.ericsson.se> Date: Mon, 29 Oct 2001 09:05:11 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: A Venkatraman , "Fairlie-Cuninghame, Robert" , Pekka Pessi , Jo Hornsby Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <3BD9902E.4F65C774@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Still a small clarification I would like to get on this issue: Assume that the UAS receives the INVITE from two separate "routes". It sends 200 to the first one, and 482 to the other. Now, the ACK to the 482 response has the same Via branch as its corresponding INVITE, but the ACK to the INVITE that generated the 200 MAY have another Via branch than the INVITE. So, my question is: IF the ACK to the 200 has another Via branch than its INVITE, is there a possibility that the ACK will be routed so that when it is received by the UAS it will contain an IDENTICAL Via branch as the ACK to the INVITE that generated 482? IF that is possible, the UAS will not know that they are two separate ACKs. Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > > Hello, > > As it was pointed out, section 13.3.1 indicates that a 482 response has > to be generated by the UAS. However, it is true that this should be a > general behavior applicable not only to INVITEs but to any method. > Furthermore, proxies should follow this behavior as well. > > We will clarify this. > > Regards, > > Gonzalo > > A Venkatraman wrote: > > > > Since the 4xx response is ACKed by the proxy, the VIA will have the same > > branch. > > If it is a 2xx, ACK may be received with a different VIA (ie from the UAC, > > if not Record-routed). In this case, the UAS will keep retransmitting the > > 200 > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Christer > > Holmberg > > Sent: Friday, October 26, 2001 9:16 AM > > To: sip@ietf.org > > Cc: Fairlie-Cuninghame, Robert; Pekka Pessi > > Subject: Re: [Sip] Handling of duplicate requests with differing request > > paths. > > > > Hi, > > > > Another question related to this: > > > > If the UAS receives multiple instances of the INVITE, it may send 200 to > > the first and then 482 to the others. > > > > Now, it also have to receive separate ACKs for all the final responses, > > so my question is: will the Via branch always be the same in the ACK as > > it was in the INVITE (or whatever request method), or how does the UAS > > map the ACK to a specific 482 (or 200)? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > >Hi Christer & Pekka, > > > > > > > >What would actually happen (eg whether the same or different tag is used > > in > > > >responses) would be implementation specific [if a UAS ignored the text > > that > > > >Jo Hornsby pointed out]. It would depend on how a negative result to the > > > >algorithm specified in Section 17.2.3 (Matching Requests To Server > > > >Transactions) is handled. > > > > > > I am not sure I understand how it can be an implementation specific > > > issue. If the UAC receives two (or more) identical 200 OK responses, > > > doesn't it always assume it is a re-transmisson? > > > > > > >However, that discussion (for INVITE anyway) is irrelevant because Bis-05 > > > >does describe the correct behavior for an INVITE request (ie send 482 > > > >response) but it is not specified for non-INVITE requests. > > > > > > > >Also Via hiding was removed from the SIP spec in bis-02 - so that is the > > > >answer to that question. :) > > > > > > I know. I had 3GPP on my mind, but the way it's done there doesn't > > > affect this. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > Regards, > > > > > > > > Robert. > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Friday, October 26, 2001 2:18 PM > > > > > To: Pekka Pessi > > > > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > > > > > Subject: Re: [Sip] Handling of duplicate requests with > > > > > differing request > > > > > p aths. > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > >In message > > > > > > > > > > Fairlie-Cuninghame, Robert > writes: > > > > > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > > > > > > > > > Does it? Both have identical to-tags. How is the original > > > > > > client going to tell difference? It does not have > > > > > a benefit of > > > > > > branch parameter. > > > > > > > > > > I agree with Pekka. There are no via headers in the response when the > > > > > UAC receives it, and if the To-tags are identical the UAC > > > > > will treat the > > > > > response as a retransmission of the final response (the UAS > > > > > will resend > > > > > the final response until it receives the ACK). > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 04:19:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07730 for ; Mon, 29 Oct 2001 04:19:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15012 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 04:19:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14479; Mon, 29 Oct 2001 03:59:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14450 for ; Mon, 29 Oct 2001 03:59:42 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07598 for ; Mon, 29 Oct 2001 03:59:39 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 29 Oct 2001 08:59:47 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Mon, 29 Oct 2001 09:01:34 +0000 From: "James Undery" To: "Jonathan Rosenberg" , "SIP" Subject: RE: [Sip] Changes in bis-05 Date: Mon, 29 Oct 2001 09:01:36 -0000 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) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 29 Oct 2001 09:01:34.0399 (UTC) FILETIME=[4F204CF0:01C16058] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Section 16.5, step 2 Updating the Request-URI, replacing > it is a MUST > > !! this is a totally unnecessary and contradictory to all > the loose > > routing discussions at the last IETF. > > > > Well, its not different from how its always been. This text is not a > statement of a decision, just a no-change from previous > versions. I believe > this issue to be the largest open issue at the moment in > the spec, and I > believe its even called out in bis-05. I never realised outbound proxies were illegal :-) Sorry my fault for being vaugue this section is describing standard proxy behaviour. I hope rewritting Request-URI was always optional. James _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 04:52:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07989 for ; Mon, 29 Oct 2001 04:52:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15654 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 04:52:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15094; Mon, 29 Oct 2001 04:25:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15062 for ; Mon, 29 Oct 2001 04:25:14 -0500 (EST) Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07763 for ; Mon, 29 Oct 2001 04:25:10 -0500 (EST) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-1.free.fr (Postfix) with ESMTP id B3D2B28E for ; Mon, 29 Oct 2001 10:25:13 +0100 (CET) Received: from imp1-1.free.fr (www-data@localhost [127.0.0.1]) by imp1-1.free.fr (8.12.1/8.12.1/Debian -1) with ESMTP id f9T9PCYa031300 for ; Mon, 29 Oct 2001 10:25:12 +0100 Received: (from www-data@localhost) by imp1-1.free.fr (8.12.1/8.12.1/Debian -1) id f9T9PBUf031291 for sip@ietf.org; Mon, 29 Oct 2001 10:25:11 +0100 To: sip@ietf.org Message-ID: <1004347511.3bdd2077494bd@imp.free.fr> Date: Mon, 29 Oct 2001 10:25:11 +0100 (MET) From: patrick.mourot@online.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 212.208.74.5 Content-Transfer-Encoding: 8bit Subject: [Sip] Search facily for mailing list Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Sirs, Is there a search engine for SIP, SIPPING mailing lists ? If yes it could be useful to activate it and so not to waste time. TIA, Patrick _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 07:32:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09521 for ; Mon, 29 Oct 2001 07:32:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18835 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 07:32:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18369; Mon, 29 Oct 2001 07:08:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18340 for ; Mon, 29 Oct 2001 07:08:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09122; Mon, 29 Oct 2001 07:07:56 -0500 (EST) Message-Id: <200110291207.HAA09122@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 29 Oct 2001 07:07:55 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc2543bis-05.txt,.ps Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP: Session Initiation Protocol Author(s) : J. Rosenberg, H. Schulzrinne et al. Filename : draft-ietf-sip-rfc2543bis-05.txt,.ps Pages : 221 Date : 26-Oct-01 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution and multimedia conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2543bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rfc2543bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011026135503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011026135503.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 09:27:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14603 for ; Mon, 29 Oct 2001 09:27:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20729 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 09:27:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20446; Mon, 29 Oct 2001 09:01:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20418 for ; Mon, 29 Oct 2001 09:01:55 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13125 for ; Mon, 29 Oct 2001 09:01:50 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9TE1rl15511 for ; Mon, 29 Oct 2001 09:01:53 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4SHMBX>; Mon, 29 Oct 2001 14:01:46 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB002A95878@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'sip@ietf.org'" Date: Mon, 29 Oct 2001 14:01:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question about version 5 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Question 1: In 16.5 it says "The Record-Route process is designed to work for any SIP request that initiates a dialog. The only such request in this specification is INVITE. Extensions to the protocol MAY define others, and the mechanisms described here will apply. The request that initiates a dialog and all refreshes (re-INVITE for example) MUST have Record-Route header values added to them if the proxy wishes to remain in the request path." But in table 3, Record-Route is optional for all request which don't create a dialog excepte INVITE. So which one takes priority, 16.5 or table 3? Question 2: In 17.1.1.3, it says:"The ACK request MUST NOT contain any Route headers." But in table 3: Route header is optional for ACK. which one takes priority, 17.1.1.3 or table 3? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 09:53:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15758 for ; Mon, 29 Oct 2001 09:53:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21517 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 09:53:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20678; Mon, 29 Oct 2001 09:22:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20646 for ; Mon, 29 Oct 2001 09:22:56 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14245 for ; Mon, 29 Oct 2001 09:22:51 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9TEMOV17227 for ; Mon, 29 Oct 2001 09:22:24 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA01094; Mon, 29 Oct 2001 08:22:22 -0600 (CST) Message-ID: <3BDD65E8.189F8D85@lucent.com> Date: Mon, 29 Oct 2001 08:21:28 -0600 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: "'sip@ietf.org'" Subject: Re: [Sip] Question about version 5 References: <475FF955A05DD411980D00508B6D5FB002A95878@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Chen, Xin (Xin)" wrote: > > Question 1: > > In 16.5 it says "The Record-Route process is designed to work for any SIP > request that initiates a dialog. The only such request in this > specification is INVITE. Extensions to the protocol MAY define others, and > the mechanisms described here will apply. The request that initiates a > dialog and all refreshes (re-INVITE for example) MUST have Record-Route > header values added to them if the proxy wishes to remain in the request > path." > > But in table 3, Record-Route is optional for all request which don't > create a dialog excepte INVITE. > > So which one takes priority, 16.5 or table 3? Xin: Once a proxy has decided to R-R and a route has been established, it is recommended that future requests within that session contain an R-R as well. The reason for this is robustness if the called UAS crashes and subsequently reboots. This change is not new, and was actually made in -00bis. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 10:24:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16873 for ; Mon, 29 Oct 2001 10:23:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22457 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 10:24:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22099; Mon, 29 Oct 2001 10:04:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22068 for ; Mon, 29 Oct 2001 10:04:45 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16279 for ; Mon, 29 Oct 2001 10:04:39 -0500 (EST) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9TF4CU00742; Mon, 29 Oct 2001 07:04:12 -0800 (PST) Received: from arunvenkw2k (dhcp-64-101-150-140.cisco.com [64.101.150.140]) by sponge.cisco.com (Mirapoint) with SMTP id AAU25583; Mon, 29 Oct 2001 09:01:26 -0600 (CST) From: "A Venkatraman" To: "Christer Holmberg" , Cc: "Fairlie-Cuninghame, Robert" , "Pekka Pessi" , "Jo Hornsby" Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Mon, 29 Oct 2001 09:08:21 -0600 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: <3BDCFFA7.49815318@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer It is mandatory to include a Contact in the 200 response to an INVITE. The ACK will therefore be sent to the CONTACT and should have the topmost VIA of the UAC or its outbound proxy. Unless, the proxies in the path have record-routed, in which case, the topmost VIA will be that of the first immediately preceding proxy from the UAS which record-routed. In both cases, the VIA of the 200 will differ from the VIA of the 482. Venkat -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Christer Holmberg Sent: Monday, October 29, 2001 1:05 AM To: sip@ietf.org Cc: A Venkatraman; Fairlie-Cuninghame, Robert; Pekka Pessi; Jo Hornsby Subject: Re: [Sip] Handling of duplicate requests with differing request paths. Hi, Still a small clarification I would like to get on this issue: Assume that the UAS receives the INVITE from two separate "routes". It sends 200 to the first one, and 482 to the other. Now, the ACK to the 482 response has the same Via branch as its corresponding INVITE, but the ACK to the INVITE that generated the 200 MAY have another Via branch than the INVITE. So, my question is: IF the ACK to the 200 has another Via branch than its INVITE, is there a possibility that the ACK will be routed so that when it is received by the UAS it will contain an IDENTICAL Via branch as the ACK to the INVITE that generated 482? IF that is possible, the UAS will not know that they are two separate ACKs. Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > > Hello, > > As it was pointed out, section 13.3.1 indicates that a 482 response has > to be generated by the UAS. However, it is true that this should be a > general behavior applicable not only to INVITEs but to any method. > Furthermore, proxies should follow this behavior as well. > > We will clarify this. > > Regards, > > Gonzalo > > A Venkatraman wrote: > > > > Since the 4xx response is ACKed by the proxy, the VIA will have the same > > branch. > > If it is a 2xx, ACK may be received with a different VIA (ie from the UAC, > > if not Record-routed). In this case, the UAS will keep retransmitting the > > 200 > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Christer > > Holmberg > > Sent: Friday, October 26, 2001 9:16 AM > > To: sip@ietf.org > > Cc: Fairlie-Cuninghame, Robert; Pekka Pessi > > Subject: Re: [Sip] Handling of duplicate requests with differing request > > paths. > > > > Hi, > > > > Another question related to this: > > > > If the UAS receives multiple instances of the INVITE, it may send 200 to > > the first and then 482 to the others. > > > > Now, it also have to receive separate ACKs for all the final responses, > > so my question is: will the Via branch always be the same in the ACK as > > it was in the INVITE (or whatever request method), or how does the UAS > > map the ACK to a specific 482 (or 200)? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > >Hi Christer & Pekka, > > > > > > > >What would actually happen (eg whether the same or different tag is used > > in > > > >responses) would be implementation specific [if a UAS ignored the text > > that > > > >Jo Hornsby pointed out]. It would depend on how a negative result to the > > > >algorithm specified in Section 17.2.3 (Matching Requests To Server > > > >Transactions) is handled. > > > > > > I am not sure I understand how it can be an implementation specific > > > issue. If the UAC receives two (or more) identical 200 OK responses, > > > doesn't it always assume it is a re-transmisson? > > > > > > >However, that discussion (for INVITE anyway) is irrelevant because Bis-05 > > > >does describe the correct behavior for an INVITE request (ie send 482 > > > >response) but it is not specified for non-INVITE requests. > > > > > > > >Also Via hiding was removed from the SIP spec in bis-02 - so that is the > > > >answer to that question. :) > > > > > > I know. I had 3GPP on my mind, but the way it's done there doesn't > > > affect this. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > Regards, > > > > > > > > Robert. > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Friday, October 26, 2001 2:18 PM > > > > > To: Pekka Pessi > > > > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; sip@ietf.org > > > > > Subject: Re: [Sip] Handling of duplicate requests with > > > > > differing request > > > > > p aths. > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > >In message > > > > > > > > > > Fairlie-Cuninghame, Robert > writes: > > > > > >>Like a 200 OK? [which sets up two subscriptions or two active calls] > > > > > > > > > > > > Does it? Both have identical to-tags. How is the original > > > > > > client going to tell difference? It does not have > > > > > a benefit of > > > > > > branch parameter. > > > > > > > > > > I agree with Pekka. There are no via headers in the response when the > > > > > UAC receives it, and if the To-tags are identical the UAC > > > > > will treat the > > > > > response as a retransmission of the final response (the UAS > > > > > will resend > > > > > the final response until it receives the ACK). > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 12:23:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20644 for ; Mon, 29 Oct 2001 12:23:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26317 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 12:23:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25129; Mon, 29 Oct 2001 11:50:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25030 for ; Mon, 29 Oct 2001 11:50:52 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19460 for ; Mon, 29 Oct 2001 11:50:48 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9TGoD010573; Mon, 29 Oct 2001 10:50:13 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9TGoD917561; Mon, 29 Oct 2001 10:50:13 -0600 (CST) Received: from lmf.ericsson.se (rmt160148.am.ericsson.se [138.85.160.148]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA27566; Mon, 29 Oct 2001 10:50:04 -0600 (CST) Message-ID: <3BDD8DA6.8DB0EE07@lmf.ericsson.se> Date: Mon, 29 Oct 2001 19:11:02 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: A Venkatraman CC: Christer Holmberg , sip@ietf.org, "Fairlie-Cuninghame, Robert" , Pekka Pessi , Jo Hornsby Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Exactly. The proxy ACKing the 482 will not be in the route set of the dialog. Therefore it will not handle the ACK for the 2xx response. Regards, Gonzalo A Venkatraman wrote: > > Christer > It is mandatory to include a Contact in the 200 response to an INVITE. > The ACK will therefore be sent to the CONTACT and should have the topmost > VIA of the UAC or its outbound proxy. > Unless, the proxies in the path have record-routed, in which case, the > topmost VIA will be that of the first immediately preceding proxy from the > UAS which record-routed. > In both cases, the VIA of the 200 will differ from the VIA of the 482. > > Venkat > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Christer > Holmberg > Sent: Monday, October 29, 2001 1:05 AM > To: sip@ietf.org > Cc: A Venkatraman; Fairlie-Cuninghame, Robert; Pekka Pessi; Jo Hornsby > Subject: Re: [Sip] Handling of duplicate requests with differing request > paths. > > Hi, > > Still a small clarification I would like to get on this issue: > > Assume that the UAS receives the INVITE from two separate "routes". It > sends 200 to the first one, and 482 to the other. > > Now, the ACK to the 482 response has the same Via branch as its > corresponding INVITE, but the ACK to the INVITE that generated the 200 > MAY have another Via branch than the INVITE. > > So, my question is: IF the ACK to the 200 has another Via branch than > its INVITE, is there a possibility that the ACK will be routed so that > when it is received by the UAS it will contain an IDENTICAL Via branch > as the ACK to the INVITE that generated 482? IF that is possible, the > UAS will not know that they are two separate ACKs. > > Regards, > > Christer Holmberg > Ericsson Finland > > Gonzalo Camarillo wrote: > > > > Hello, > > > > As it was pointed out, section 13.3.1 indicates that a 482 response has > > to be generated by the UAS. However, it is true that this should be a > > general behavior applicable not only to INVITEs but to any method. > > Furthermore, proxies should follow this behavior as well. > > > > We will clarify this. > > > > Regards, > > > > Gonzalo > > > > A Venkatraman wrote: > > > > > > Since the 4xx response is ACKed by the proxy, the VIA will have the same > > > branch. > > > If it is a 2xx, ACK may be received with a different VIA (ie from the > UAC, > > > if not Record-routed). In this case, the UAS will keep retransmitting > the > > > 200 > > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > Christer > > > Holmberg > > > Sent: Friday, October 26, 2001 9:16 AM > > > To: sip@ietf.org > > > Cc: Fairlie-Cuninghame, Robert; Pekka Pessi > > > Subject: Re: [Sip] Handling of duplicate requests with differing > request > > > paths. > > > > > > Hi, > > > > > > Another question related to this: > > > > > > If the UAS receives multiple instances of the INVITE, it may send 200 to > > > the first and then 482 to the others. > > > > > > Now, it also have to receive separate ACKs for all the final responses, > > > so my question is: will the Via branch always be the same in the ACK as > > > it was in the INVITE (or whatever request method), or how does the UAS > > > map the ACK to a specific 482 (or 200)? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > > > >Hi Christer & Pekka, > > > > > > > > > >What would actually happen (eg whether the same or different tag is > used > > > in > > > > >responses) would be implementation specific [if a UAS ignored the > text > > > that > > > > >Jo Hornsby pointed out]. It would depend on how a negative result to > the > > > > >algorithm specified in Section 17.2.3 (Matching Requests To Server > > > > >Transactions) is handled. > > > > > > > > I am not sure I understand how it can be an implementation specific > > > > issue. If the UAC receives two (or more) identical 200 OK responses, > > > > doesn't it always assume it is a re-transmisson? > > > > > > > > >However, that discussion (for INVITE anyway) is irrelevant because > Bis-05 > > > > >does describe the correct behavior for an INVITE request (ie send 482 > > > > >response) but it is not specified for non-INVITE requests. > > > > > > > > > >Also Via hiding was removed from the SIP spec in bis-02 - so that is > the > > > > >answer to that question. :) > > > > > > > > I know. I had 3GPP on my mind, but the way it's done there doesn't > > > > affect this. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > Regards, > > > > > > > > > > Robert. > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > Sent: Friday, October 26, 2001 2:18 PM > > > > > > To: Pekka Pessi > > > > > > Cc: Fairlie-Cuninghame@agni.research.nokia.com; Robert; > sip@ietf.org > > > > > > Subject: Re: [Sip] Handling of duplicate requests with > > > > > > differing request > > > > > > p aths. > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > >In message > > > > > > > > > > > > Fairlie-Cuninghame, Robert > writes: > > > > > > >>Like a 200 OK? [which sets up two subscriptions or two active > calls] > > > > > > > > > > > > > > Does it? Both have identical to-tags. How is the > original > > > > > > > client going to tell difference? It does not have > > > > > > a benefit of > > > > > > > branch parameter. > > > > > > > > > > > > I agree with Pekka. There are no via headers in the response when > the > > > > > > UAC receives it, and if the To-tags are identical the UAC > > > > > > will treat the > > > > > > response as a retransmission of the final response (the UAS > > > > > > will resend > > > > > > the final response until it receives the ACK). > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 12:29:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20880 for ; Mon, 29 Oct 2001 12:29:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26399 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 12:29:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26050; Mon, 29 Oct 2001 12:05:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26021 for ; Mon, 29 Oct 2001 12:05:29 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19967 for ; Mon, 29 Oct 2001 12:05:25 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9TH4MY03008; Mon, 29 Oct 2001 11:04:32 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9TH4L921442; Mon, 29 Oct 2001 11:04:21 -0600 (CST) Received: from lmf.ericsson.se (rmt160148.am.ericsson.se [138.85.160.148]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA28351; Mon, 29 Oct 2001 11:04:19 -0600 (CST) Message-ID: <3BDD90FD.C6D05E67@lmf.ericsson.se> Date: Mon, 29 Oct 2001 19:25:17 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-05 References: <3BD9C8A0.2B1EECCC@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > This no longer permits an SDP body without m lines, that isn't an offer. > (Not surprising, because it would be difficult to describe this > situation without getting into the details of SDP.) > > Personally, I think this change is a considerable *improvement*, and I > am happy to see it made. But it *is* a change, and probably ought to be > discussed, if it hasn't been already. > I believe that this has already been discussed for a while. Even in MMUSIC we had to change considerably the FID draft (3 or 4 IETF meetings ago) because SIP did not allow three SDPs in the INVITE-200 OK-ACK hand-shake anymore. I do not think this merits further discussions. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 12:48:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21592 for ; Mon, 29 Oct 2001 12:48:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26981 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 12:49:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26292; Mon, 29 Oct 2001 12:21:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26261 for ; Mon, 29 Oct 2001 12:21:05 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20590 for ; Mon, 29 Oct 2001 12:21:00 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 29 Oct 2001 17:21:09 UT Received: from jhornsby ([193.195.52.40]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Mon, 29 Oct 2001 17:22:57 +0000 From: "Jo Hornsby" To: "Shan Lu" , Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Mon, 29 Oct 2001 17:21:04 -0000 Message-ID: <000001c1609e$16aa18b0$2834c3c1@eu.ubiquity.net> 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 In-Reply-To: <000a01c1609a$2491a780$eb00000a@SAJAK> X-OriginalArrivalTime: 29 Oct 2001 17:22:57.0745 (UTC) FILETIME=[5A329C10:01C1609E] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > Assume that the UAS receives the INVITE from two separate "routes". It > > sends 200 to the first one, and 482 to the other. > > > > Q1. Is 482 the proper response? This isn't a loop, is it? It's important not to get too hung-up on the default Reason Phrases. An implementor is free to use "Request Merged", or sommat, as the Reason Phrase that accompanies the 482. 482 is specified by bis-05, and I think fits very well semantically with the "classical" notion of a 482. > Q2. 200 followd by 4xx works if the paths are due to a forking proxy, > which will sit there collecting responses and send upstream the "best > one". Now what if the requests travel different paths because a > stateless load balancer distributes requests round robin to a farm of > proxies and multiple requests end up in the same UAS? In this case, both > 200 and 4xx are received by the UAC. This load balancer is broken, then; or, at least, the system that it is working in as a whole is broken. It should not be possible to observe any such behaviour from any other SIP client's / server's perspective. > Let's further assume that the UAS > responds with 1xx to the first request -- an early dialog is setup. > According to 13.2.2.3, the subsequest 4xx causes the UAC to terminate > the INVITE transaction, which means the call is dropped. And what if the > 4xx arrives before 1xx? Does this mean that a load balancer here has to > be at least transaction stateful? This is also a valid case when > different proxies are used for retransmissions. Retransmissions should always go to the same server (proxy). > Q3. An INVITE is forked and then merged at a stateless proxy which > precedes the UAS. The topmost VIA of the requests are the same. So the > UAS thinks they are retransmissions. Hmmm...I don't think that this can happen in practise, but we might need to tighten up the definition of how unique a branch ID is to make it explicit. I may be misreading, but it seems to me that bis-05 only guarantees uniqueness within a particular transaction (line 2188). I think it might be inferred that it's actually also going to be unique with a set of N transactions that share a particular { Request-URI, From, To, Call-ID, CSeq }-tuple; however, I might just be being optimistic. Step 3 of section 16.5 does suggest a format for forming branch IDs, but this is not mandatory (as is right, I do think). I would prefer to see something that explicitly states that branch IDs should be unique with a particular client's space. > 200 Oks are returned, but through > different paths. Now you have one dialog setup b/w UAC and UAS, but > through different routes. Will this cause problem for proxies (SF) all > the path? Hopefully the above will solve that problem. - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 13:11:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22306 for ; Mon, 29 Oct 2001 13:11:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27557 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 13:11:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25243; Mon, 29 Oct 2001 11:53:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25215 for ; Mon, 29 Oct 2001 11:53:31 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19548 for ; Mon, 29 Oct 2001 11:53:25 -0500 (EST) Received: (qmail 28448 invoked from network); 29 Oct 2001 16:46:18 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 29 Oct 2001 16:46:18 -0000 From: "Shan Lu" To: Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Mon, 29 Oct 2001 11:52:49 -0500 Message-ID: <000a01c1609a$2491a780$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] > On Behalf Of Christer > Holmberg > Sent: Monday, October 29, 2001 1:05 AM > To: sip@ietf.org > Cc: A Venkatraman; Fairlie-Cuninghame, Robert; Pekka Pessi; > Jo Hornsby > Subject: Re: [Sip] Handling of duplicate requests with > differing request > paths. > > > Hi, > > Still a small clarification I would like to get on this issue: > > Assume that the UAS receives the INVITE from two separate "routes". It > sends 200 to the first one, and 482 to the other. > Q1. Is 482 the proper response? This isn't a loop, is it? Q2. 200 followd by 4xx works if the paths are due to a forking proxy, which will sit there collecting responses and send upstream the "best one". Now what if the requests travel different paths because a stateless load balancer distributes requests round robin to a farm of proxies and multiple requests end up in the same UAS? In this case, both 200 and 4xx are received by the UAC. Let's further assume that the UAS responds with 1xx to the first request -- an early dialog is setup. According to 13.2.2.3, the subsequest 4xx causes the UAC to terminate the INVITE transaction, which means the call is dropped. And what if the 4xx arrives before 1xx? Does this mean that a load balancer here has to be at least transaction stateful? This is also a valid case when different proxies are used for retransmissions. Q3. An INVITE is forked and then merged at a stateless proxy which precedes the UAS. The topmost VIA of the requests are the same. So the UAS thinks they are retransmissions. 200 Oks are returned, but through different paths. Now you have one dialog setup b/w UAC and UAS, but through different routes. Will this cause problem for proxies (SF) all the path? Thanks, Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 13:20:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22575 for ; Mon, 29 Oct 2001 13:20:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27637 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 13:19:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27048; Mon, 29 Oct 2001 12:50:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27019 for ; Mon, 29 Oct 2001 12:50:43 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21701 for ; Mon, 29 Oct 2001 12:50:40 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9THoeY08439; Mon, 29 Oct 2001 11:50:40 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9THoe207420; Mon, 29 Oct 2001 11:50:40 -0600 (CST) Received: from lmf.ericsson.se (rmt160148.am.ericsson.se [138.85.160.148]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA00070; Mon, 29 Oct 2001 11:50:37 -0600 (CST) Message-ID: <3BDD9BD6.22A6200E@lmf.ericsson.se> Date: Mon, 29 Oct 2001 20:11:34 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: Shan Lu , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <000001c1609e$16aa18b0$2834c3c1@eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Jo Hornsby wrote: > > > > Assume that the UAS receives the INVITE from two separate "routes". It > > > sends 200 to the first one, and 482 to the other. > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > It's important not to get too hung-up on the > default Reason Phrases. An implementor is > free to use "Request Merged", or sommat, as > the Reason Phrase that accompanies the 482. > 482 is specified by bis-05, and I think > fits very well semantically with the > "classical" notion of a 482. > > > Q2. 200 followd by 4xx works if the paths are due to a forking proxy, > > which will sit there collecting responses and send upstream the "best > > one". Now what if the requests travel different paths because a > > stateless load balancer distributes requests round robin to a farm of > > proxies and multiple requests end up in the same UAS? In this case, both > > 200 and 4xx are received by the UAC. > > This load balancer is broken, then; or, at least, > the system that it is working in as a whole is > broken. It should not be possible to observe > any such behaviour from any other SIP client's / > server's perspective. > > > Let's further assume that the UAS > > responds with 1xx to the first request -- an early dialog is setup. > > According to 13.2.2.3, the subsequest 4xx causes the UAC to terminate > > the INVITE transaction, which means the call is dropped. And what if the > > 4xx arrives before 1xx? Does this mean that a load balancer here has to > > be at least transaction stateful? This is also a valid case when > > different proxies are used for retransmissions. > > Retransmissions should always go to the same > server (proxy). > > > Q3. An INVITE is forked and then merged at a stateless proxy which > > precedes the UAS. The topmost VIA of the requests are the same. So the > > UAS thinks they are retransmissions. > > Hmmm...I don't think that this can happen in > practise, but we might need to tighten up > the definition of how unique a branch ID is > to make it explicit. > > I may be misreading, but it seems to me that > bis-05 only guarantees uniqueness within a > particular transaction (line 2188). I think > it might be inferred that it's actually also > going to be unique with a set of N transactions > that share a particular { Request-URI, From, > To, Call-ID, CSeq }-tuple; however, I might > just be being optimistic. > > Step 3 of section 16.5 does suggest a format > for forming branch IDs, but this is not > mandatory (as is right, I do think). I would > prefer to see something that explicitly states > that branch IDs should be unique with a > particular client's space. > What we want is that the UAS (or proxy) behind the stateless proxy can distinguish between both incoming requests (each of them has traversed a differenet set of nodes). If the stateless proxy calculates the brach using, besides request-URI, Cseq, etc, the Via header of the incoming request, the problem is resolved. The UAS will see different top Via headers even though both requests com from the same stateless proxy. We will add that in either section 16.5 or 16.9. Regards, Gonzalo > > 200 Oks are returned, but through > > different paths. Now you have one dialog setup b/w UAC and UAS, but > > through different routes. Will this cause problem for proxies (SF) all > > the path? > > Hopefully the above will solve that problem. > > - Jo. > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 16:30:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27661 for ; Mon, 29 Oct 2001 16:30:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01855 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 16:30:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00777; Mon, 29 Oct 2001 15:47:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00746 for ; Mon, 29 Oct 2001 15:47:52 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26423 for ; Mon, 29 Oct 2001 15:47:47 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A0774F270156; Mon, 29 Oct 2001 15:47:51 -0500 Message-ID: <002b01c160ba$966b9120$2300000a@acmepacket.com> From: "Bob Penfield" To: Date: Mon, 29 Oct 2001 15:45:03 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] bis-05: Terminating a session Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Section 15 is a great improvement, however it might still be misinterpreted for callee behavior, especially by folks new to SIP. Section 15 begins: Terminating a session is done either with the BYE request, or the CANCEL request, depending on the state of the dialog. Either caller or callee can terminate, and may do so for any reason. One might interpret this as allowing a callee to send CANCEL or a callee to send BYE prior to an "established" dialog. This whole area of terminating session has caused a lot of confusion and discussion and I think we need to be really clear. I suggest section 15 begin: "Either the caller or callee may terminate a session for any reason. A caller terminates a session either with BYE or CANCEL depending on the state of the dialog. A callee uses BYE to terminate an established dialog." Somewhere near line 1957, it should be noted that the callee terminates an early dialog by sending a non-2xx final response to the INVITE. As far as issue#202 is concerned, I think that this is the right solution. In section 15.1.1 at line 1972, ".. creation of dialog (either early or established)." should be "... creation of dialog (established for the callee, early or established for the caller)". cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 16:41:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27967 for ; Mon, 29 Oct 2001 16:41:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01954 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 16:41:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01362; Mon, 29 Oct 2001 16:11:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01333 for ; Mon, 29 Oct 2001 16:11:09 -0500 (EST) Received: from urdvg135.cms.usa.net (urdvg135.cms.usa.net [204.68.25.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27189 for ; Mon, 29 Oct 2001 16:10:59 -0500 (EST) Received: (qmail 8355 invoked from network); 29 Oct 2001 21:18:31 -0000 Received: from unknown (HELO cpdvg203.cms.usa.net) (165.212.11.13) by outbound.postoffice.net with SMTP; 29 Oct 2001 21:18:31 -0000 Received: (qmail 10700 invoked by uid 60001); 29 Oct 2001 21:10:30 -0000 Message-ID: <20011029211030.10698.qmail@cpdvg203.cms.usa.net> Received: from 165.212.11.13 by mx09 for [152.148.210.138] via web-mailer(34FM.0700.21.01) on Mon Oct 29 21:10:30 GMT 2001 Date: 29 Oct 2001 16:10:30 EST From: "Alex S.M" To: X-Mailer: USANET web-mailer (34FM.0700.21.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA01334 Subject: [Sip] SIP MIBs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, I am wondering if there is a way to find the MIBs for SIP or I need to extract them from draft-ietf-sip-mib-03.txt? Any new update or RFC? Do I need ALL 4 modules defined in the draft (SIP-COMMON.MIB, SIP-SERVER.MIB, SIP-TC.MIB, SIP-UA.MIB)? and whether I need to alter them or not? Thanks, alex ____________________________________________________________________ Get free e-mail and a permanent address at http://www.amexmail.com/?A=1 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 17:53:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29867 for ; Mon, 29 Oct 2001 17:53:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04066 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 17:53:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02262; Mon, 29 Oct 2001 16:59:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02231 for ; Mon, 29 Oct 2001 16:59:43 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28552 for ; Mon, 29 Oct 2001 16:59:37 -0500 (EST) Received: (qmail 19873 invoked from network); 29 Oct 2001 21:52:30 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 29 Oct 2001 21:52:30 -0000 From: "Shan Lu" To: "IETF SIP Mailing List" Date: Mon, 29 Oct 2001 16:59:02 -0500 Message-ID: <001501c160c4$ebad1550$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Bis-05 question: CANCEL Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, Section 9.1, line 1180 "CANCEL MUST NOT be sent if no provisional response has been received". Why? If my user dials a number and then hangs up, I want to cancel the invite ASAP. If the destiation is a PSTN number, I don't want it to allocate resources and ring the phone, if at all possible. According to section 9.1, it seems that in absence of 100 Trying, an INVITE can only be cancelled AFTER the phone has been rung. I think this is an unnecessary requirement. Sure the the CANCEL immediately following INVITE might arrive at the UAS before the INVITE. So be it. If you worry about the ordering so much, you might as well worry that the provisional response may get lost or the CANCEl may get crossed with 200 OK. If the rule is there to take care of CANCEL for non-INVITEs, then it should say so. In any case, "MUST NOT" is way too strong. Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 17:53:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29874 for ; Mon, 29 Oct 2001 17:53:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04080 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 17:53:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02902; Mon, 29 Oct 2001 17:11:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02873 for ; Mon, 29 Oct 2001 17:11:31 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28998 for ; Mon, 29 Oct 2001 17:11:25 -0500 (EST) Received: (qmail 20766 invoked from network); 29 Oct 2001 22:04:14 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 29 Oct 2001 22:04:14 -0000 From: "Shan Lu" To: "'Jo Hornsby'" , Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Mon, 29 Oct 2001 17:10:46 -0500 Message-ID: <001601c160c6$8f239730$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <000001c1609e$16aa18b0$2834c3c1@eu.ubiquity.net> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Monday, October 29, 2001 12:21 PM > To: Shan Lu; sip@ietf.org > Subject: RE: [Sip] Handling of duplicate requests with > differing request paths. > > > > > Assume that the UAS receives the INVITE from two separate > "routes". It > > > sends 200 to the first one, and 482 to the other. > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > It's important not to get too hung-up on the > default Reason Phrases. An implementor is > free to use "Request Merged", or sommat, as > the Reason Phrase that accompanies the 482. > 482 is specified by bis-05, and I think > fits very well semantically with the > "classical" notion of a 482. This sounds like a pretty good reason to define a new cause code rather than let everybody come up with their own reason phase. > > > Q2. 200 followd by 4xx works if the paths are due to a > forking proxy, > > which will sit there collecting responses and send upstream > the "best > > one". Now what if the requests travel different paths because a > > stateless load balancer distributes requests round robin to > a farm of > > proxies and multiple requests end up in the same UAS? In > this case, both > > 200 and 4xx are received by the UAC. > > This load balancer is broken, then; or, at least, > the system that it is working in as a whole is > broken. It should not be possible to observe > any such behaviour from any other SIP client's / > server's perspective. > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 which both are sent upstream to UAC. The question is: does 4xx terminate the transaction according to 13.2.2.3. > > Let's further assume that the UAS > > responds with 1xx to the first request -- an early dialog is setup. > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > terminate > > the INVITE transaction, which means the call is dropped. > And what if the > > 4xx arrives before 1xx? Does this mean that a load balancer > here has to > > be at least transaction stateful? This is also a valid case when > > different proxies are used for retransmissions. > > Retransmissions should always go to the same > server (proxy). In a perfect world, yes. What if the proxy that forwards initial INVITE goes down? Let's say its backup (through DNS lookup) has a slightly different view of the network topology and sends retransmissions through a different path. Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 17:53:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29895 for ; Mon, 29 Oct 2001 17:53:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04094 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 17:53:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02130; Mon, 29 Oct 2001 16:51:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02099 for ; Mon, 29 Oct 2001 16:51:43 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28233 for ; Mon, 29 Oct 2001 16:51:37 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9TLnqb7004855; Mon, 29 Oct 2001 16:49:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Oct 2001 16:51:06 -0500 Message-ID: From: Jonathan Rosenberg To: "'Chen, Xin (Xin)'" , "'sip@ietf.org'" Subject: RE: [Sip] Question about version 5 Date: Mon, 29 Oct 2001 16:51:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] > Sent: Monday, October 29, 2001 9:02 AM > To: 'sip@ietf.org' > Subject: [Sip] Question about version 5 > > > Question 1: > > In 16.5 it says "The Record-Route process is designed to work > for any SIP > request that initiates a dialog. The only such request in > this specification > is INVITE. Extensions to the protocol MAY define others, and > the mechanisms > described here will apply. The request that initiates a dialog and all > refreshes (re-INVITE for example) MUST have Record-Route > header values added > to them if the proxy wishes to remain in the request path." > > But in table 3, Record-Route is optional for all request > which don't create > a dialog excepte INVITE. > > So which one takes priority, 16.5 or table 3? I think Vijay has adequately answered this. The Record-Route in INVITE is the only one that is useful, and the specification ONLY defines semantics when its in an INVITE. It can be present in other methods so that a proxy which doesn't know about methods can record-route everything, in order to be sure it doesn't miss anything. Thats in the spirit of the sentence at line 2271. We will add a sentence that talks explicitly about other methods as well. > > Question 2: > > In 17.1.1.3, it says:"The ACK request MUST NOT contain any > Route headers." > > But in table 3: Route header is optional for ACK. > > which one takes priority, 17.1.1.3 or table 3? For ACK to non-200, ACK MUST NOT be present. That is based on the context of section 17.1.1.3, which is only talking about this type of ACK. When talking about ACK for 200, thats handled as for requests within a dialog, and it does have Route. Table 3 needs to be updated to reflect this, and any other differences in rules for ACK v. ACK-200. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 17:53:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29912 for ; Mon, 29 Oct 2001 17:53:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04108 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 17:53:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03157; Mon, 29 Oct 2001 17:24:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03126 for ; Mon, 29 Oct 2001 17:24:06 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29297 for ; Mon, 29 Oct 2001 17:24:00 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9TMN3026563; Mon, 29 Oct 2001 16:23:03 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9TMN2i03375; Mon, 29 Oct 2001 16:23:02 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id QAA21307; Mon, 29 Oct 2001 16:23:02 -0600 (CST) Reply-To: To: "'Shan Lu'" , "'Jo Hornsby'" , Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Mon, 29 Oct 2001 16:23:00 -0600 Message-ID: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> 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 V6.00.2600.0000 In-Reply-To: <001601c160c6$8f239730$eb00000a@SAJAK> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Two issues: I was pretty sure that we had decided not to return an error code at all (since the forked messages may have gone through proxies that added proxy-require headers, etc); this would leave the clients to sort things out. That notwithstanding, if we are choosing a status code for this situation, we should make sure it doesn't override any other "useful" status codes at the proxy (by being a lower number). For example, a UA receiving a "482 Request Merged" is not ever useful. A 500 response, however, might convey some information. To avoid having a "Request Merged" response overriding a useful response, I'd suggest that we select status code 599 for request merging. Unless, of course, my first assertion was correct (and I do believe that it is): proxies shouldn't merge requests at all, and this should be a UAS issue. /a > -----Original Message----- > From: Shan Lu [mailto:shanlu@sentito.com] > Sent: Monday, October 29, 2001 4:11 PM > To: 'Jo Hornsby'; sip@ietf.org > Subject: RE: [Sip] Handling of duplicate requests with > differing request > paths. > > > > > > -----Original Message----- > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > Sent: Monday, October 29, 2001 12:21 PM > > To: Shan Lu; sip@ietf.org > > Subject: RE: [Sip] Handling of duplicate requests with > > differing request paths. > > > > > > > > Assume that the UAS receives the INVITE from two separate > > "routes". It > > > > sends 200 to the first one, and 482 to the other. > > > > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > > > It's important not to get too hung-up on the > > default Reason Phrases. An implementor is > > free to use "Request Merged", or sommat, as > > the Reason Phrase that accompanies the 482. > > 482 is specified by bis-05, and I think > > fits very well semantically with the > > "classical" notion of a 482. > > This sounds like a pretty good reason to define a new cause > code rather > than let everybody come up with their own reason phase. > > > > > > Q2. 200 followd by 4xx works if the paths are due to a > > forking proxy, > > > which will sit there collecting responses and send upstream > > the "best > > > one". Now what if the requests travel different paths because a > > > stateless load balancer distributes requests round robin to > > a farm of > > > proxies and multiple requests end up in the same UAS? In > > this case, both > > > 200 and 4xx are received by the UAC. > > > > This load balancer is broken, then; or, at least, > > the system that it is working in as a whole is > > broken. It should not be possible to observe > > any such behaviour from any other SIP client's / > > server's perspective. > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 > which both are sent upstream to UAC. The question is: does > 4xx terminate > the transaction according to 13.2.2.3. > > > > Let's further assume that the UAS > > > responds with 1xx to the first request -- an early dialog > is setup. > > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > > terminate > > > the INVITE transaction, which means the call is dropped. > > And what if the > > > 4xx arrives before 1xx? Does this mean that a load balancer > > here has to > > > be at least transaction stateful? This is also a valid case when > > > different proxies are used for retransmissions. > > > > Retransmissions should always go to the same > > server (proxy). > > In a perfect world, yes. What if the proxy that forwards > initial INVITE > goes down? Let's say its backup (through DNS lookup) has a slightly > different view of the network topology and sends > retransmissions through > a different path. > > > > Shan Lu > sentitO Networks > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 17:53:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29861 for ; Mon, 29 Oct 2001 17:53:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04052 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 17:53:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02727; Mon, 29 Oct 2001 17:03:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02693 for ; Mon, 29 Oct 2001 17:03:47 -0500 (EST) Received: from rwcxch02.clarent.com ([208.205.112.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28735 for ; Mon, 29 Oct 2001 17:03:41 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Oct 2001 14:00:37 -0800 Received: from rwcjfmule01 (rwc-jfmule01.clarent.com [10.1.75.229]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TYCRKL7Q; Mon, 29 Oct 2001 14:00:26 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Alex S.M'" , sip@ietf.org Subject: RE: [Sip] SIP MIBs Date: Mon, 29 Oct 2001 14:01:26 -0800 Message-ID: <009501c160c5$42b449e0$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011029211030.10698.qmail@cpdvg203.cms.usa.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Alex, The MIB modules from draft-ietf-sip-mib-03 are available at: http://groups.yahoo.com/group/sip-mib/files/ Jean-Francois. alex wrote: > Hi, > > I am wondering if there is a way to find the MIBs for SIP or > I need to extract > them from draft-ietf-sip-mib-03.txt? > Any new update or RFC? > Do I need ALL 4 modules defined in the draft (SIP-COMMON.MIB, > SIP-SERVER.MIB, > SIP-TC.MIB, SIP-UA.MIB)? > and whether I need to alter them or not? > > > Thanks, > alex _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 19:19:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00738 for ; Mon, 29 Oct 2001 19:19:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA05798 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 19:19:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04637; Mon, 29 Oct 2001 18:15:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04606 for ; Mon, 29 Oct 2001 18:15:51 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00180 for ; Mon, 29 Oct 2001 18:15:46 -0500 (EST) Received: (qmail 25400 invoked from network); 29 Oct 2001 23:08:40 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 29 Oct 2001 23:08:40 -0000 From: "Shan Lu" To: "IETF SIP Mailing List" Date: Mon, 29 Oct 2001 18:15:12 -0500 Message-ID: <001701c160cf$8f78cd00$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Bis-05 question: re-invite Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, Section 14.1, line 1937, "If a UAS generates a 2xx and never receives an ACK, it SHOULD generate a re-invite with an offer equal to last session description sent to peer." I think this creates unnecessary burden on the UA and doesn't achieve much. If the re-invite is to change codecs, then the UAS would have to reserve DSP resources before it sends 200 ok. Now with this requirement, the UAS has to keep the resource reserved for the duration of currect invite transaction (31 s) plus potentially another 31 s for the re-invite that it generates. If you have any confidence in the invite-200-ack retransmission scheme, the UAS should consider the UAC down upon seven 200 oks and no ACK. Let's consider the case where the connection from UA1 to UA2 goes down after the intitial re-invite. UA2 does not receive ACK for this re-invite. So UA2 generates its own re-invite. UA1 responds with 200 OK but never received by UA2. So next UA1 would re-invite. It's just a mess. Furthermore, if the initial re-invite has no sdp, what is the benefit of having UAS resend its sdp offer? That is equivalent to having the UAC resend the re-invite upon no response. BTW, I believe section 14 should describe what happens when re-invite does not generate any response -- terminate the call. Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 19:40:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00925 for ; Mon, 29 Oct 2001 19:40:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06230 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 19:37:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05225; Mon, 29 Oct 2001 18:36:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05134 for ; Mon, 29 Oct 2001 18:36:48 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00348 for ; Mon, 29 Oct 2001 18:36:22 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9TNZP023247; Mon, 29 Oct 2001 17:35:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9TNZPK17701; Mon, 29 Oct 2001 17:35:25 -0600 (CST) Received: from lmf.ericsson.se (rmt160132.am.ericsson.se [138.85.160.132]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA26167; Mon, 29 Oct 2001 17:35:21 -0600 (CST) Message-ID: <3BDDECA1.2C1FC4E3@lmf.ericsson.se> Date: Tue, 30 Oct 2001 01:56:17 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com CC: "'Shan Lu'" , "'Jo Hornsby'" , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > Unless, of course, my first assertion was correct (and I do believe > that it is): proxies shouldn't merge requests at all, and this > should be a UAS issue. > Yes, the one that returns the 482 is the UAS. The only thing a proxy does is to compute a different branch in the Via for the requests that will be merged by the UAS. Regards, Gonzalo > /a > > > -----Original Message----- > > From: Shan Lu [mailto:shanlu@sentito.com] > > Sent: Monday, October 29, 2001 4:11 PM > > To: 'Jo Hornsby'; sip@ietf.org > > Subject: RE: [Sip] Handling of duplicate requests with > > differing request > > paths. > > > > > > > > > > > -----Original Message----- > > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > > Sent: Monday, October 29, 2001 12:21 PM > > > To: Shan Lu; sip@ietf.org > > > Subject: RE: [Sip] Handling of duplicate requests with > > > differing request paths. > > > > > > > > > > > Assume that the UAS receives the INVITE from two separate > > > "routes". It > > > > > sends 200 to the first one, and 482 to the other. > > > > > > > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > > > > > It's important not to get too hung-up on the > > > default Reason Phrases. An implementor is > > > free to use "Request Merged", or sommat, as > > > the Reason Phrase that accompanies the 482. > > > 482 is specified by bis-05, and I think > > > fits very well semantically with the > > > "classical" notion of a 482. > > > > This sounds like a pretty good reason to define a new cause > > code rather > > than let everybody come up with their own reason phase. > > > > > > > > > Q2. 200 followd by 4xx works if the paths are due to a > > > forking proxy, > > > > which will sit there collecting responses and send upstream > > > the "best > > > > one". Now what if the requests travel different paths because a > > > > stateless load balancer distributes requests round robin to > > > a farm of > > > > proxies and multiple requests end up in the same UAS? In > > > this case, both > > > > 200 and 4xx are received by the UAC. > > > > > > This load balancer is broken, then; or, at least, > > > the system that it is working in as a whole is > > > broken. It should not be possible to observe > > > any such behaviour from any other SIP client's / > > > server's perspective. > > > > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > > stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 > > which both are sent upstream to UAC. The question is: does > > 4xx terminate > > the transaction according to 13.2.2.3. > > > > > > Let's further assume that the UAS > > > > responds with 1xx to the first request -- an early dialog > > is setup. > > > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > > > terminate > > > > the INVITE transaction, which means the call is dropped. > > > And what if the > > > > 4xx arrives before 1xx? Does this mean that a load balancer > > > here has to > > > > be at least transaction stateful? This is also a valid case when > > > > different proxies are used for retransmissions. > > > > > > Retransmissions should always go to the same > > > server (proxy). > > > > In a perfect world, yes. What if the proxy that forwards > > initial INVITE > > goes down? Let's say its backup (through DNS lookup) has a slightly > > different view of the network topology and sends > > retransmissions through > > a different path. > > > > > > > > Shan Lu > > sentitO Networks > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Oct 29 22:19:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03849 for ; Mon, 29 Oct 2001 22:19:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08720 for sip-archive@odin.ietf.org; Mon, 29 Oct 2001 22:19:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07273; Mon, 29 Oct 2001 20:51:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07242 for ; Mon, 29 Oct 2001 20:51:23 -0500 (EST) Received: from server640.peel5.com (IDENT:root@[216.28.47.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01939 for ; Mon, 29 Oct 2001 20:51:19 -0500 (EST) Received: from [208.205.112.130] (helo=rwc-jfmule01.packetizer.com) by server640.peel5.com with esmtp (Exim 3.33 #1) id 15yO3b-0002ap-00; Mon, 29 Oct 2001 20:51:11 -0500 Message-Id: <5.1.0.14.2.20011029174342.028bfec0@mail.packetizer.com> X-Sender: jfmule@mail.packetizer.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Oct 2001 17:50:41 -0800 To: sip@ietf.org From: Jean-Francois Mule Subject: Re: [Sip] T.38 real-time fax draft status - draft02 submitted In-Reply-To: <00b301c160e2$948ae310$e54b010a@rwcjfmule01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server640.peel5.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - packetizer.com Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org fyi, a new revision of the SIP I-D on Real-time fax has been submitted today. Since this is now a deliverable in sipping, it will be announced and further discussed on the sipping mailing list. Jean-Francois Mule. >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >Jean-Francois Mule >Sent: Friday, October 05, 2001 7:28 AM >To: 'Christer Holmberg'; sip@ietf.org >Subject: RE: [Sip] T.38 draft status > > > >I am planning to submit an updated draft-02 very soon based on: > - changes to indicate echo cancelation/silence suppression media >attributes for fax pass-through (done), > - comments & suggestions submitted by Bill Sulzen of Cisco (on-going) > - first testing at the August SIPit event between 2 gateway vendors. >The first fax calls were successful and we agreed to add some text to >indicate how the faxratemanagement media attribute should be >"negotiated" (done) > >Recent events have prevented me from being on target but I expect the >draft to be out within 2 weeks. >Regards, >Jean-Francois. > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Christer Holmberg > > Sent: Friday, October 05, 2001 4:13 AM > > To: sip@ietf.org > > Subject: [Sip] T.38 draft status > > > > > > > > Hi, > > > > The -01 version of the T.38 fax draft has expired. I wonder > > if there is > > any ongoing update work, and when the next version will be released. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 02:18:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21955 for ; Tue, 30 Oct 2001 02:18:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20132 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 02:18:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11390; Tue, 30 Oct 2001 00:42:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11361 for ; Tue, 30 Oct 2001 00:42:35 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06459 for ; Tue, 30 Oct 2001 00:42:32 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9U5gVf29529; Tue, 30 Oct 2001 06:42:31 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9U5gUB25082; Tue, 30 Oct 2001 07:42:31 +0200 (EET) Message-ID: <3BDE3DC0.3B5CB4A8@lmf.ericsson.se> Date: Tue, 30 Oct 2001 07:42:24 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: adam.roach@ericsson.com, "'Shan Lu'" , "'Jo Hornsby'" , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> <3BDDECA1.2C1FC4E3@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Consider the following scenario: |-----P2-----| UAC ---P1 P3--- UAS |------------| Now, the UAC sends an INVITE, which is forked by P1. One INVITE goes via P2 and P3, and the other INVITE via P3 only. The P1-P2-P3 INVITE reaches the UAS first, and a 200 (including a Contact header) is sent back. Then, the P1-P3 INVITE reaches the UAS, and the UAS sends 482 back. Now we come to the ACKs. If P3 inserted Record-Route for BOTH INVITEs, will there be any difference in the Via headers of the two ACKs? And, if the 482 was sent all the way back to P1, or the UAC, and BOTH P1 and P3 inserted Record-Route, won't we again get the same situation, because the ACKs will use exactly the same route? Someone said that this may not be a real-life case, but I don't agree on that. And, isn't 3GPP talking about some kind of "inbound" proxy also? Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > > Hi, > > > Unless, of course, my first assertion was correct (and I do believe > > that it is): proxies shouldn't merge requests at all, and this > > should be a UAS issue. > > > > Yes, the one that returns the 482 is the UAS. The only thing a proxy > does is to compute a different branch in the Via for the requests that > will be merged by the UAS. > > Regards, > > Gonzalo > > > /a > > > > > -----Original Message----- > > > From: Shan Lu [mailto:shanlu@sentito.com] > > > Sent: Monday, October 29, 2001 4:11 PM > > > To: 'Jo Hornsby'; sip@ietf.org > > > Subject: RE: [Sip] Handling of duplicate requests with > > > differing request > > > paths. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > > > Sent: Monday, October 29, 2001 12:21 PM > > > > To: Shan Lu; sip@ietf.org > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > differing request paths. > > > > > > > > > > > > > > Assume that the UAS receives the INVITE from two separate > > > > "routes". It > > > > > > sends 200 to the first one, and 482 to the other. > > > > > > > > > > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > > > > > > > It's important not to get too hung-up on the > > > > default Reason Phrases. An implementor is > > > > free to use "Request Merged", or sommat, as > > > > the Reason Phrase that accompanies the 482. > > > > 482 is specified by bis-05, and I think > > > > fits very well semantically with the > > > > "classical" notion of a 482. > > > > > > This sounds like a pretty good reason to define a new cause > > > code rather > > > than let everybody come up with their own reason phase. > > > > > > > > > > > > Q2. 200 followd by 4xx works if the paths are due to a > > > > forking proxy, > > > > > which will sit there collecting responses and send upstream > > > > the "best > > > > > one". Now what if the requests travel different paths because a > > > > > stateless load balancer distributes requests round robin to > > > > a farm of > > > > > proxies and multiple requests end up in the same UAS? In > > > > this case, both > > > > > 200 and 4xx are received by the UAC. > > > > > > > > This load balancer is broken, then; or, at least, > > > > the system that it is working in as a whole is > > > > broken. It should not be possible to observe > > > > any such behaviour from any other SIP client's / > > > > server's perspective. > > > > > > > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > > > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > > > stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 > > > which both are sent upstream to UAC. The question is: does > > > 4xx terminate > > > the transaction according to 13.2.2.3. > > > > > > > > Let's further assume that the UAS > > > > > responds with 1xx to the first request -- an early dialog > > > is setup. > > > > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > > > > terminate > > > > > the INVITE transaction, which means the call is dropped. > > > > And what if the > > > > > 4xx arrives before 1xx? Does this mean that a load balancer > > > > here has to > > > > > be at least transaction stateful? This is also a valid case when > > > > > different proxies are used for retransmissions. > > > > > > > > Retransmissions should always go to the same > > > > server (proxy). > > > > > > In a perfect world, yes. What if the proxy that forwards > > > initial INVITE > > > goes down? Let's say its backup (through DNS lookup) has a slightly > > > different view of the network topology and sends > > > retransmissions through > > > a different path. > > > > > > > > > > > > Shan Lu > > > sentitO Networks > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 02:18:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21970 for ; Tue, 30 Oct 2001 02:18:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20146 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 02:18:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11506; Tue, 30 Oct 2001 00:55:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11477 for ; Tue, 30 Oct 2001 00:55:45 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06518 for ; Tue, 30 Oct 2001 00:55:43 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9U5tiC02965 for ; Tue, 30 Oct 2001 06:55:44 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9U5thB25313 for ; Tue, 30 Oct 2001 07:55:43 +0200 (EET) Message-ID: <3BDE40D9.D77E29E3@lmf.ericsson.se> Date: Tue, 30 Oct 2001 07:55:37 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 482 handling by proxies Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, This is related to the thread about handling of duplicated requests, but this issue is related to the proxies. Assume that a proxy, P1, forks an INVITE. The UAS receives the INVITE, and decides to process that. After that it receives the same INVITE, via another route, so it returns 482. Then, P1 receives that 482. However, it may take time until the UAS sends a final response for the first INVITE. It may not even send a provisional response, but there may also be 18xs, PRACKs, COMETs, INFOs, and who knows what. Is P1 required to be able to handle all this, and not send the 482 back to the UAC? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 03:38:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22692 for ; Tue, 30 Oct 2001 03:38:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22186 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 03:38:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20983; Tue, 30 Oct 2001 02:52:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20955 for ; Tue, 30 Oct 2001 02:52:32 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22437 for ; Tue, 30 Oct 2001 02:52:29 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9U7qIC05152; Tue, 30 Oct 2001 08:52:18 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9U7qHB28761; Tue, 30 Oct 2001 09:52:17 +0200 (EET) Message-ID: <3BDE5C2A.FF1180BE@lmf.ericsson.se> Date: Tue, 30 Oct 2001 09:52:10 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF SIP Mailing List CC: Jonathan Rosenberg , "'Shan Lu'" Subject: Re: [Sip] Bis-05 question: CANCEL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Section 9.1, line 1180 "CANCEL MUST NOT be sent if no provisional >>response has been received". >> >>Why? > >Because of a race condition. Lets say a user sends an INVITE, and then >immediately hangs up. So, a CANCEL is sent. The INVITE is lost, but the >CANCEL is not. The CANCEL arrives at the UAS, but there is not a matching >INVITE. So, a 481 is sent in response to the CANCEL, and the transaction is >discarded. Then, the INVITE arrives, and is accepted a few minutes later. > >The result is that a loss (or delay) of the original request can basically >eliminate the effectiveness of the CANCEL. If the INVITE gets to the UAS AFTER the CANCEL, and starts generating provisional responses, the UAC can send a new CANCEL. We have the same situation if the UAS doesn't generate provisional responses at all. It may accept the INVITE and return 200, so in that case the UAC will have to ACK/BYE. This is also the case for the CANCEL/200 race condition mentioned later in the mail. >>If my user dials a number and then hangs up, I want to cancel >>the invite ASAP. >Please do not confuse user interfaces with protocols. Of course a user can >hang up immediately. The question is: do we really want to add all this "buffering" into the protocol? We need it for PRACK, and that's bad enough. Isn't it better to define procedures how these race conditions should be handled instead, ie by sending CANCEL/ACK/BYE/whatever...? >The restriction on not sending CANCEL until 1xx is a protocol issue. If the >user hangs up immediately, the UA has to buffer the CANCEL until a 1xx or >until the transaction times out altogether, due to some error or something. >I will point out that this is nothing more than implementing an HOL blocking >scheme to provide sender-side ordering. If SIP were run over TCP, and we did >not introduce this explicit requirement, but merely stated that all requests >for a call go over the same tcp connection, we would get exactly this >effect. Since SIP can't always run over TCP, I need to introduce it here. I just wonder how a client using TCP is going to handle call setup situations with PRACKs, COMETs and INFOs.... >>If the destiation is a PSTN number, I don't want it to allocate >>resources and ring the phone, if at all possible. According to section >>9.1, it seems that in absence of 100 Trying, > >If a server can't offer a final answer in 200ms, its supposed to send a 100 >Trying. Bis-05 firms this, and places transmission of the 100 into the >transaction layer itself, so that its basically always sent. So, there will >not be a case of the absence of a 100 trying, at least. I think pretty much >all stateful proxies I know of send 100 immediately. Even if the PROXY does send 100, and the UAC sends CANCEL after that, it still doesn't mean that the UAS is going to receive the INVITE before the CANCEL, does it (even if they are using the same route from a SIP application point of view)? >>Sure the the CANCEL immediately following INVITE might >>arrive at the UAS before the INVITE. So be it. >Well, except that it doesn't work. Someone needs to maintain ordering - the >client or the server. It makes a lot more sense for the client to do it, >since the burden should, in fact, be on it as the requestor of the service >(there are DoS attacks opened up otherwise). Furthermore, you can have this >problem at a proxy in addition to a UAS. The state problem is more >troublesome there. I still think that the easiest solution, if the UAC receives a non-487 response to a INVITE it tried to CANCEL, is to simply ACK and BYE(if it was a 200 OK final response). No buffering at all... >>If you worry about the ordering so much, you might as well worry that the >>provisional response may get lost or the CANCEl may get crossed with 200 OK. >Provisional responses are not meant to be reliable in SIP, so there loss is >not important for correctness. CANCEL/2xx crossing is indeed handled; if >this happens the UAC sends a BYE. Exactly! So, why can't it always do so? >There is an additional race condition we have found, which is 2xx to INVITE >and BYE crossing on the wire. In this case, its a similar restriction - the >BYE cannot be sent until the ACK has been received. Otherwise, the BYE may >beat the 2xx, and be discarded since it does not match a call leg. Again. The BYE may fail, but when the final response to the INVITE is received the UAC ACK and BYE again. Simple, and no buffering needed... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 03:38:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22693 for ; Tue, 30 Oct 2001 03:38:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22177 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 03:38:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20302; Tue, 30 Oct 2001 02:27:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20271 for ; Tue, 30 Oct 2001 02:27:13 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22025 for ; Tue, 30 Oct 2001 02:27:11 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9U7PSb7007156; Tue, 30 Oct 2001 02:25:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Oct 2001 02:26:42 -0500 Message-ID: From: Jonathan Rosenberg To: "'Shan Lu'" , IETF SIP Mailing List Subject: RE: [Sip] Bis-05 question: CANCEL Date: Tue, 30 Oct 2001 02:26:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Shan Lu [mailto:shanlu@sentito.com] > Sent: Monday, October 29, 2001 4:59 PM > To: IETF SIP Mailing List > Subject: [Sip] Bis-05 question: CANCEL > > > Hi all, > > Section 9.1, line 1180 "CANCEL MUST NOT be sent if no provisional > response has been received". > > Why? Because of a race condition. Lets say a user sends an INVITE, and then immediately hangs up. So, a CANCEL is sent. The INVITE is lost, but the CANCEL is not. The CANCEL arrives at the UAS, but there is not a matching INVITE. So, a 481 is sent in response to the CANCEL, and the transaction is discarded. Then, the INVITE arrives, and is accepted a few minutes later. The result is that a loss (or delay) of the original request can basically eliminate the effectiveness of the CANCEL. > > If my user dials a number and then hangs up, I want to cancel > the invite > ASAP. Please do not confuse user interfaces with protocols. Of course a user can hang up immediately. The restriction on not sending CANCEL until 1xx is a protocol issue. If the user hangs up immediately, the UA has to buffer the CANCEL until a 1xx or until the transaction times out altogether, due to some error or something. I will point out that this is nothing more than implementing an HOL blocking scheme to provide sender-side ordering. If SIP were run over TCP, and we did not introduce this explicit requirement, but merely stated that all requests for a call go over the same tcp connection, we would get exactly this effect. Since SIP can't always run over TCP, I need to introduce it here. > If the destiation is a PSTN number, I don't want it to allocate > resources and ring the phone, if at all possible. According to section > 9.1, it seems that in absence of 100 Trying, If a server can't offer a final answer in 200ms, its supposed to send a 100 Trying. Bis-05 firms this, and places transmission of the 100 into the transaction layer itself, so that its basically always sent. So, there will not be a case of the absence of a 100 trying, at least. I think pretty much all stateful proxies I know of send 100 immediately. > an INVITE can only be > cancelled AFTER the phone has been rung. I think this is an > unnecessary > requirement. As I said, this is nothing more than the same ordering we would see with usage of a persistent tcp connection. > Sure the the CANCEL immediately following INVITE might > arrive at the UAS before the INVITE. So be it. Well, except that it doesn't work. Someone needs to maintain ordering - the client or the server. It makes a lot more sense for the client to do it, since the burden should, in fact, be on it as the requestor of the service (there are DoS attacks opened up otherwise). Furthermore, you can have this problem at a proxy in addition to a UAS. The state problem is more troublesome there. > If you worry about the > ordering so much, you might as well worry that the > provisional response > may get lost or the CANCEl may get crossed with 200 OK. Provisional responses are not meant to be reliable in SIP, so there loss is not important for correctness. CANCEL/2xx crossing is indeed handled; if this happens the UAC sends a BYE. There is an additional race condition we have found, which is 2xx to INVITE and BYE crossing on the wire. In this case, its a similar restriction - the BYE cannot be sent until the ACK has been received. Otherwise, the BYE may beat the 2xx, and be discarded since it does not match a call leg. > > If the rule is there to take care of CANCEL for non-INVITEs, then it > should say so. In any case, "MUST NOT" is way too strong. No, the rule is there primarily for INVITE. I believe the MUST NOT is appropriate in order to guarantee correctness. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 06:01:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24121 for ; Tue, 30 Oct 2001 06:01:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA25822 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 06:01:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23636; Tue, 30 Oct 2001 04:37:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23603 for ; Tue, 30 Oct 2001 04:36:58 -0500 (EST) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23317 for ; Tue, 30 Oct 2001 04:36:54 -0500 (EST) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id KAA07886; Tue, 30 Oct 2001 10:35:37 +0100 (MET) Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) with ESMTP id f9U9Z8a06034; Tue, 30 Oct 2001 10:35:08 +0100 X-Authentication-Warning: musette.kom.e-technik.tu-darmstadt.de: rac owned process doing -bs Date: Tue, 30 Oct 2001 10:35:07 +0100 (CET) From: Ralf Ackermann To: cc: , , , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Q: SIP support in MS XP Messenger? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, i have a question on the status of support for SIP in the Microsoft XP Messenger. Since MS claims this product uses SIP (for e.g. placing audio calls but also Instant Messaging) - has anybody tested, whether - Microsoft XP Messenger (most recent version is 4.5) interoperates with SIP infrastructure components (e.g. sipd from Columbia University) ? - Microsoft XP Messenger interoperates with any SIP soft- or hardphones (e.g. Pingtel xpressa, VOCAL UA ...)? Any hints/experiences are highly appreciated (since we didn't identify configuration options / "hooks" that indicate such support yet). Best regards ralf -- Best regards, Ralf Ackermann --------------------------------------------------------------- Hosting the IP Telephony Field Trial for the Darmstadt Region --------------------------------------------------------------- Ralf Ackermann _ rac@KOM.tu-darmstadt.de Industrial Process and |/ | | |\/| Merckstrasse 25 System Communications |\ |_| | | 64283 Darmstadt, Germany Tel.: (+49) 6151 16-6138 Fax: (+49) 6151 16-6152 --------------------------------------------------------------- http://www.kom.e-technik.tu-darmstadt.de/~rac --------------------------------------------------------------- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 07:57:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26723 for ; Tue, 30 Oct 2001 07:57:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28173 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 07:57:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25449; Tue, 30 Oct 2001 05:54:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25418 for ; Tue, 30 Oct 2001 05:54:28 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24055 for ; Tue, 30 Oct 2001 05:54:24 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9UAsQI06545 for ; Tue, 30 Oct 2001 05:54:27 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4S2AP4>; Tue, 30 Oct 2001 10:54:20 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB002A95885@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] Question about version 5 Date: Tue, 30 Oct 2001 10:54:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan and Vijay, Thanks for your respond. But I got confused by having different understanding with the answers. My understanding of what Vijay said is: The proxy needs to record-route every request, otherwise it might be kicked off the dialog becuse the UE will reconstruct the route set according to the lastest record-route header it receives, for example form a 200 OK for PRACK. My understanding of what Jonathan said is: The UE only constrcuts the route set according to the record-route header from the INVITE, subsequent record-route header received will be ignored. So even if a proxy doesn't understand any method even INVITE, but because it will record-route everything passed, so the proxy will definititly record-route the INVITE, so it will not be kicked off the dialog. I believe I must misundersant something here, please point them out for me, thanks. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 29 October 2001 21:51 To: 'Chen, Xin (Xin)'; 'sip@ietf.org' Subject: RE: [Sip] Question about version 5 > -----Original Message----- > From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] > Sent: Monday, October 29, 2001 9:02 AM > To: 'sip@ietf.org' > Subject: [Sip] Question about version 5 > > > Question 1: > > In 16.5 it says "The Record-Route process is designed to work > for any SIP > request that initiates a dialog. The only such request in > this specification > is INVITE. Extensions to the protocol MAY define others, and > the mechanisms > described here will apply. The request that initiates a dialog and all > refreshes (re-INVITE for example) MUST have Record-Route > header values added > to them if the proxy wishes to remain in the request path." > > But in table 3, Record-Route is optional for all request > which don't create > a dialog excepte INVITE. > > So which one takes priority, 16.5 or table 3? I think Vijay has adequately answered this. The Record-Route in INVITE is the only one that is useful, and the specification ONLY defines semantics when its in an INVITE. It can be present in other methods so that a proxy which doesn't know about methods can record-route everything, in order to be sure it doesn't miss anything. Thats in the spirit of the sentence at line 2271. We will add a sentence that talks explicitly about other methods as well. > > Question 2: > > In 17.1.1.3, it says:"The ACK request MUST NOT contain any > Route headers." > > But in table 3: Route header is optional for ACK. > > which one takes priority, 17.1.1.3 or table 3? For ACK to non-200, ACK MUST NOT be present. That is based on the context of section 17.1.1.3, which is only talking about this type of ACK. When talking about ACK for 200, thats handled as for requests within a dialog, and it does have Route. Table 3 needs to be updated to reflect this, and any other differences in rules for ACK v. ACK-200. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 08:04:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27073 for ; Tue, 30 Oct 2001 08:04:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28739 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 08:04:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27055; Tue, 30 Oct 2001 07:03:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27024 for ; Tue, 30 Oct 2001 07:03:51 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24580 for ; Tue, 30 Oct 2001 07:03:48 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9UC3J508340 for ; Tue, 30 Oct 2001 07:03:19 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4S2DWD>; Tue, 30 Oct 2001 12:03:13 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB002A95887@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'sip@ietf.org'" Date: Tue, 30 Oct 2001 12:03:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question about ACK for None-200 Response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Bis-05 says: "The ACK request MUST NOT contain any Route headers." In line 2467, Bis 05 says: For a stateless proxy receiveing CANCEL and non-Routed ACK requests, it MUST generate the same choice as their associated INVITE. Bis-05 also says: "The ACK request MUST NOT contain any Route headers." I think these two pargraphes are conflicted each other. How can a stateless proxy generate the same choice as the INVITE for a non-Routed ACK if the ACK doesn't have a route header? A INVITE will have a route header which is used by proxy to route the request, but without the route header, when the stateless proxy gets that ACK, it will be very confused about where to forward this. Could anyone point out what I missed here? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 10:15:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03536 for ; Tue, 30 Oct 2001 10:15:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04682 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:15:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02793; Tue, 30 Oct 2001 09:41:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02759 for ; Tue, 30 Oct 2001 09:41:56 -0500 (EST) Received: from iconnect (host213-122-9-5.btconnect.com [213.122.9.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02285 for ; Tue, 30 Oct 2001 09:41:42 -0500 (EST) Received: from [172.1.1.127] by iconnect (ArGoSoft Mail Server, Version 1.5 (1.5.0.8)); Tue, 30 Oct 2001 14:41:34 +0000 Message-ID: <005a01c16150$88e3e840$7f0101ac@engineering> From: "A. Peter Mee" To: Date: Tue, 30 Oct 2001 14:38:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] OT: OOB-DTMF Clients Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, My apologies for the off topic post, however it appears this is the only avenue I have yet to check. I am in the process of testing a SIP product but have yet to locate a client that is able to perform out-of-band DTMF. Would, perchance, any of you know of such a beast and where I might get one from please? Best regards, A. Peter Mee _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 10:15:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03533 for ; Tue, 30 Oct 2001 10:15:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04676 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:15:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02375; Tue, 30 Oct 2001 09:35:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02284 for ; Tue, 30 Oct 2001 09:35:34 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02010 for ; Tue, 30 Oct 2001 09:35:29 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9UEYT006480; Tue, 30 Oct 2001 08:34:29 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9UEYTj16123; Tue, 30 Oct 2001 08:34:29 -0600 (CST) Received: from lmf.ericsson.se (rmt160120.am.ericsson.se [138.85.160.120]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA22855; Tue, 30 Oct 2001 08:34:23 -0600 (CST) Message-ID: <3BDEBF5E.D3DB3A3C@lmf.ericsson.se> Date: Tue, 30 Oct 2001 16:55:26 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: adam.roach@ericsson.com, "'Shan Lu'" , "'Jo Hornsby'" , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> <3BDDECA1.2C1FC4E3@lmf.ericsson.se> <3BDE3DC0.3B5CB4A8@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Christer Holmberg wrote: > > Hi, > > Consider the following scenario: > > |-----P2-----| > UAC ---P1 P3--- UAS > |------------| > > Now, the UAC sends an INVITE, which is forked by P1. One INVITE goes via > P2 and P3, and the other INVITE via P3 only. > > The P1-P2-P3 INVITE reaches the UAS first, and a 200 (including a > Contact header) is sent back. Then, the P1-P3 INVITE reaches the UAS, > and the UAS sends 482 back. > > Now we come to the ACKs. If P3 inserted Record-Route for BOTH INVITEs, > will there be any difference in the Via headers of the two ACKs? > Yes because P3 inserted a different branch in the Via header for each of the two INVITEs that it forwarded to the UAS. That's how you can distinguish the ACKs. The ACK for the non-2xx final response will have the same branch as the previous INVITE and thus it will be absorved by the server transaction. When the ACK for the 2xx final response arrives, there is no server transaction that matches the ACK's top Via header (line 2770 of bis-05 PDF version). Therefore, the ACK for the 2xx final response will be handled by the Transaction User (in this case the UAS core). Regards, Gonzalo > And, if the 482 was sent all the way back to P1, or the UAC, and BOTH P1 > and P3 inserted Record-Route, won't we again get the same situation, > because the ACKs will use exactly the same route? > > Someone said that this may not be a real-life case, but I don't agree on > that. And, isn't 3GPP talking about some kind of "inbound" proxy also? > > Regards, > > Christer Holmberg > Ericsson Finland > > Gonzalo Camarillo wrote: > > > > Hi, > > > > > Unless, of course, my first assertion was correct (and I do believe > > > that it is): proxies shouldn't merge requests at all, and this > > > should be a UAS issue. > > > > > > > Yes, the one that returns the 482 is the UAS. The only thing a proxy > > does is to compute a different branch in the Via for the requests that > > will be merged by the UAS. > > > > Regards, > > > > Gonzalo > > > > > /a > > > > > > > -----Original Message----- > > > > From: Shan Lu [mailto:shanlu@sentito.com] > > > > Sent: Monday, October 29, 2001 4:11 PM > > > > To: 'Jo Hornsby'; sip@ietf.org > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > differing request > > > > paths. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > > > > Sent: Monday, October 29, 2001 12:21 PM > > > > > To: Shan Lu; sip@ietf.org > > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > > differing request paths. > > > > > > > > > > > > > > > > > Assume that the UAS receives the INVITE from two separate > > > > > "routes". It > > > > > > > sends 200 to the first one, and 482 to the other. > > > > > > > > > > > > > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > > > > > > > > > It's important not to get too hung-up on the > > > > > default Reason Phrases. An implementor is > > > > > free to use "Request Merged", or sommat, as > > > > > the Reason Phrase that accompanies the 482. > > > > > 482 is specified by bis-05, and I think > > > > > fits very well semantically with the > > > > > "classical" notion of a 482. > > > > > > > > This sounds like a pretty good reason to define a new cause > > > > code rather > > > > than let everybody come up with their own reason phase. > > > > > > > > > > > > > > > Q2. 200 followd by 4xx works if the paths are due to a > > > > > forking proxy, > > > > > > which will sit there collecting responses and send upstream > > > > > the "best > > > > > > one". Now what if the requests travel different paths because a > > > > > > stateless load balancer distributes requests round robin to > > > > > a farm of > > > > > > proxies and multiple requests end up in the same UAS? In > > > > > this case, both > > > > > > 200 and 4xx are received by the UAC. > > > > > > > > > > This load balancer is broken, then; or, at least, > > > > > the system that it is working in as a whole is > > > > > broken. It should not be possible to observe > > > > > any such behaviour from any other SIP client's / > > > > > server's perspective. > > > > > > > > > > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > > > > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > > > > stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 > > > > which both are sent upstream to UAC. The question is: does > > > > 4xx terminate > > > > the transaction according to 13.2.2.3. > > > > > > > > > > Let's further assume that the UAS > > > > > > responds with 1xx to the first request -- an early dialog > > > > is setup. > > > > > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > > > > > terminate > > > > > > the INVITE transaction, which means the call is dropped. > > > > > And what if the > > > > > > 4xx arrives before 1xx? Does this mean that a load balancer > > > > > here has to > > > > > > be at least transaction stateful? This is also a valid case when > > > > > > different proxies are used for retransmissions. > > > > > > > > > > Retransmissions should always go to the same > > > > > server (proxy). > > > > > > > > In a perfect world, yes. What if the proxy that forwards > > > > initial INVITE > > > > goes down? Let's say its backup (through DNS lookup) has a slightly > > > > different view of the network topology and sends > > > > retransmissions through > > > > a different path. > > > > > > > > > > > > > > > > Shan Lu > > > > sentitO Networks > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 10:30:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04012 for ; Tue, 30 Oct 2001 10:30:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05249 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:30:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04474; Tue, 30 Oct 2001 10:05:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04381 for ; Tue, 30 Oct 2001 10:05:20 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03276 for ; Tue, 30 Oct 2001 10:05:15 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9UF4fv19233; Tue, 30 Oct 2001 10:04:41 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA24222; Tue, 30 Oct 2001 09:04:33 -0600 (CST) Message-ID: <3BDEC149.6BDD5C5E@lucent.com> Date: Tue, 30 Oct 2001 09:03:37 -0600 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: Re: [Sip] Question about version 5 References: <475FF955A05DD411980D00508B6D5FB002A95885@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Chen, Xin (Xin)" wrote: > > Jonathan and Vijay, > > Thanks for your respond. But I got confused by having different > understanding with the answers. > > My understanding of what Vijay said is: The proxy needs to record-route > every request, otherwise it might be kicked off the dialog becuse the UE > will reconstruct the route set according to the lastest record-route > headerit receives, for example form a 200 OK for PRACK. > > My understanding of what Jonathan said is: The UE only constrcuts the > route set according to the record-route header from the INVITE, subsequent > record-route header received will be ignored. So even if a proxy doesn't > understand any method even INVITE, but because it will record-route > everything passed, so the proxy will definititly record-route the INVITE, > so it will not be kicked off the dialog. > > I believe I must misundersant something here, please point them out for > me, Xin: The UE will NOT as you say above, "reconstruct the route set according to the lastest record-route". The Route set is constructed once -- after the INVITE/200 OK exchange. Proxies insert R-R for robustness, in case the UAS crashes. If a UAS does NOT crash during a session, subsequent re-INVITEs do NOT alter the Route set. Consider, for example if a UAS crashes after establishing a session, through one or more R-R'ing proxy. The UAC detects the crash of the UAS and attempts to re-constitute the session with a backup of the crashed UAS. When the re-INVITE goes through the the same R-R proxies, they insert a R-R header anyway. This new re-INVITE gets to the backup peer of the crashed UAS, which accepts the session. Since the re-INVITE contains the same set of R-R headers inserted by the same set of proxies traversed, the backup peer now has the same Route set as its peer (modulo the last entry in the Route set). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 10:30:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04035 for ; Tue, 30 Oct 2001 10:30:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05288 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:30:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00650; Tue, 30 Oct 2001 09:19:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00619 for ; Tue, 30 Oct 2001 09:19:09 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00850 for ; Tue, 30 Oct 2001 09:19:04 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9UEIrf21941; Tue, 30 Oct 2001 15:18:53 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9UEIqB13506; Tue, 30 Oct 2001 16:18:52 +0200 (EET) Message-ID: <3BDEB6C4.DF72048B@lmf.ericsson.se> Date: Tue, 30 Oct 2001 16:18:44 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: <3BDE40D9.D77E29E3@lmf.ericsson.se> <017c01c1614b$c01c34c0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Bob, >Yes. The proxy is suppose to collect the non-2xx final responses, and >when it has heard from all the branches and all of them are non-2xx final >responses, it sends one non-2xx final response upstream to the UAC. If it >had received any 2xx final response(s), which it would send upstream >immediately, it does not send any non-2xx upstream. Yes. I was just worried about cases where it actually may take a relatively long time before the 200 final response is sent, due to other call setup actions (PRACK, INFO etc), because I guess the proxy won't wait "forever" for the final response until it takes some actions (of course, in a real-life situation the call setup probably won't be that long) for the pending legs. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 10:30:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04064 for ; Tue, 30 Oct 2001 10:30:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05326 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:30:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03305; Tue, 30 Oct 2001 09:52:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03276 for ; Tue, 30 Oct 2001 09:52:57 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02640 for ; Tue, 30 Oct 2001 09:52:48 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9UEqoC17095; Tue, 30 Oct 2001 15:52:50 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9UEqoB14684; Tue, 30 Oct 2001 16:52:50 +0200 (EET) Message-ID: <3BDEBEB9.983B7AB@lmf.ericsson.se> Date: Tue, 30 Oct 2001 16:52:41 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: adam.roach@ericsson.com, "'Shan Lu'" , "'Jo Hornsby'" , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> <3BDDECA1.2C1FC4E3@lmf.ericsson.se> <3BDE3DC0.3B5CB4A8@lmf.ericsson.se> <3BDEBF5E.D3DB3A3C@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Hi, >> >>Consider the following scenario: >> >> |-----P2-----| >> UAC ---P1 P3--- UAS >> |------------| >> >>Now, the UAC sends an INVITE, which is forked by P1. One INVITE goes via >>P2 and P3, and the other INVITE via P3 only. >> >>The P1-P2-P3 INVITE reaches the UAS first, and a 200 (including a >>Contact header) is sent back. Then, the P1-P3 INVITE reaches the UAS, >>and the UAS sends 482 back. >> >>Now we come to the ACKs. If P3 inserted Record-Route for BOTH INVITEs, >>will there be any difference in the Via headers of the two ACKs? >> > >Yes because P3 inserted a different branch in the Via header for each of >the two INVITEs that it forwarded to the UAS. That's how you can >distinguish the ACKs. The ACK for the non-2xx final response will have >the same branch as the previous INVITE and thus it will be absorved by >the server transaction. When the ACK for the 2xx final response arrives, >there is no server transaction that matches the ACK's top Via header >(line 2770 of bis-05 PDF version). Therefore, the ACK for the 2xx final >response will be handled by the Transaction User (in this case the UAS >core). True. Thanks! It would, though, be good if the branch value in the ACK to the 200 could be the same as the branch in the INVITE, so that they could be directly matched. It would also be more saft, since the UAS doesn't have to ASSUME an ACK belongs to the INVITE/200 just because it can't find a matching branch value... Of course, that would require that the branch is generated in some other way, and still is unique for each leg, than currently... Regards, Christer Holmberg Ericsson Finland > Regards, > > Gonzalo > > > And, if the 482 was sent all the way back to P1, or the UAC, and BOTH P1 > > and P3 inserted Record-Route, won't we again get the same situation, > > because the ACKs will use exactly the same route? > > > > Someone said that this may not be a real-life case, but I don't agree on > > that. And, isn't 3GPP talking about some kind of "inbound" proxy also? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Gonzalo Camarillo wrote: > > > > > > Hi, > > > > > > > Unless, of course, my first assertion was correct (and I do believe > > > > that it is): proxies shouldn't merge requests at all, and this > > > > should be a UAS issue. > > > > > > > > > > Yes, the one that returns the 482 is the UAS. The only thing a proxy > > > does is to compute a different branch in the Via for the requests that > > > will be merged by the UAS. > > > > > > Regards, > > > > > > Gonzalo > > > > > > > /a > > > > > > > > > -----Original Message----- > > > > > From: Shan Lu [mailto:shanlu@sentito.com] > > > > > Sent: Monday, October 29, 2001 4:11 PM > > > > > To: 'Jo Hornsby'; sip@ietf.org > > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > > differing request > > > > > paths. > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > > > > > Sent: Monday, October 29, 2001 12:21 PM > > > > > > To: Shan Lu; sip@ietf.org > > > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > > > differing request paths. > > > > > > > > > > > > > > > > > > > > Assume that the UAS receives the INVITE from two separate > > > > > > "routes". It > > > > > > > > sends 200 to the first one, and 482 to the other. > > > > > > > > > > > > > > > > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > > > > > > > > > > > It's important not to get too hung-up on the > > > > > > default Reason Phrases. An implementor is > > > > > > free to use "Request Merged", or sommat, as > > > > > > the Reason Phrase that accompanies the 482. > > > > > > 482 is specified by bis-05, and I think > > > > > > fits very well semantically with the > > > > > > "classical" notion of a 482. > > > > > > > > > > This sounds like a pretty good reason to define a new cause > > > > > code rather > > > > > than let everybody come up with their own reason phase. > > > > > > > > > > > > > > > > > > Q2. 200 followd by 4xx works if the paths are due to a > > > > > > forking proxy, > > > > > > > which will sit there collecting responses and send upstream > > > > > > the "best > > > > > > > one". Now what if the requests travel different paths because a > > > > > > > stateless load balancer distributes requests round robin to > > > > > > a farm of > > > > > > > proxies and multiple requests end up in the same UAS? In > > > > > > this case, both > > > > > > > 200 and 4xx are received by the UAC. > > > > > > > > > > > > This load balancer is broken, then; or, at least, > > > > > > the system that it is working in as a whole is > > > > > > broken. It should not be possible to observe > > > > > > any such behaviour from any other SIP client's / > > > > > > server's perspective. > > > > > > > > > > > > > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > > > > > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > > > > > stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 > > > > > which both are sent upstream to UAC. The question is: does > > > > > 4xx terminate > > > > > the transaction according to 13.2.2.3. > > > > > > > > > > > > Let's further assume that the UAS > > > > > > > responds with 1xx to the first request -- an early dialog > > > > > is setup. > > > > > > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > > > > > > terminate > > > > > > > the INVITE transaction, which means the call is dropped. > > > > > > And what if the > > > > > > > 4xx arrives before 1xx? Does this mean that a load balancer > > > > > > here has to > > > > > > > be at least transaction stateful? This is also a valid case when > > > > > > > different proxies are used for retransmissions. > > > > > > > > > > > > Retransmissions should always go to the same > > > > > > server (proxy). > > > > > > > > > > In a perfect world, yes. What if the proxy that forwards > > > > > initial INVITE > > > > > goes down? Let's say its backup (through DNS lookup) has a slightly > > > > > different view of the network topology and sends > > > > > retransmissions through > > > > > a different path. > > > > > > > > > > > > > > > > > > > > Shan Lu > > > > > sentitO Networks > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > New York, NY 10027 > > > USA Gonzalo.Camarillo@ericsson.com > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 10:33:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04217 for ; Tue, 30 Oct 2001 10:33:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05603 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:33:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02678; Tue, 30 Oct 2001 09:40:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02647 for ; Tue, 30 Oct 2001 09:40:39 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02215 for ; Tue, 30 Oct 2001 09:40:34 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9UEe6v06706 for ; Tue, 30 Oct 2001 09:40:06 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA11642; Tue, 30 Oct 2001 08:40:04 -0600 (CST) Message-ID: <3BDEBB8C.A4561DFA@lucent.com> Date: Tue, 30 Oct 2001 08:39:08 -0600 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: SIP LIST Subject: Re: [Sip] Question about ACK for None-200 Response References: <475FF955A05DD411980D00508B6D5FB002A95887@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Chen, Xin (Xin)" wrote: > > Bis-05 says: "The ACK request MUST NOT contain any Route headers." > > In line 2467, Bis 05 says: For a stateless proxy receiveing CANCEL and > non-Routed ACK requests, it MUST generate the same choice as their > associated INVITE. > > Bis-05 also says: "The ACK request MUST NOT contain any Route headers." The section you are referring the above quote from is Section 17.1.1.3, which talks about an ACK to a non-2xx response to an INVITE. These ACKs are hop by hop, and do NOT contain Route headers. ACKs for 2xx responses to an INVITE are end to end and their processing is outlined elsewhere in -05bis (I am still getting familiar with it -- started the process of "un"- burning -04bis sections from my brain). These ACKs can (and indeed MUST if some SIP entity R-R'ed) contain a Route. > I think these two pargraphes are conflicted each other. How can a > stateless proxy generate the same choice as the INVITE for a non-Routed > ACK if the ACK doesn't have a route header? A INVITE will have a route > header which is used by proxy to route the request, but without the route > header, when the stateless proxy gets that ACK, it will be very confused > about where to forward this. An INVITE will not always have a Route header; it will only do so if one of the SIP entities in the signaling path R-R'ed. The question boils down to where, in the absence of a Route, does a stateless proxy send an ACK or CANCEL. ACK and CANCEL are really pseudo-requests since they depend on another transaction, namely INVITE, to do their job. As such, they should be routed to the same host that the original INVITE went to. A stateless proxy can do so by using the modulo N hash of the Call-ID value as the uniform random number while weighing the results from a DNS SRV lookup. See section 24 in -05 bis; towards the end of the section for more information. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 10:33:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04236 for ; Tue, 30 Oct 2001 10:33:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05716 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:33:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00476; Tue, 30 Oct 2001 09:08:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00446 for ; Tue, 30 Oct 2001 09:08:09 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00305 for ; Tue, 30 Oct 2001 09:08:05 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A44212A00170; Tue, 30 Oct 2001 09:08:02 -0500 Message-ID: <017c01c1614b$c01c34c0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" , References: <3BDE40D9.D77E29E3@lmf.ericsson.se> Subject: Re: [Sip] 482 handling by proxies Date: Tue, 30 Oct 2001 09:04:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit see inline ----- Original Message ----- From: "Christer Holmberg" To: Sent: Tuesday, October 30, 2001 12:55 AM Subject: [Sip] 482 handling by proxies > > Hi, > > This is related to the thread about handling of duplicated requests, but > this issue is related to the proxies. > > Assume that a proxy, P1, forks an INVITE. The UAS receives the INVITE, > and decides to process that. After that it receives the same INVITE, via > another route, so it returns 482. > > Then, P1 receives that 482. However, it may take time until the UAS > sends a final response for the first INVITE. It may not even send a > provisional response, but there may also be 18xs, PRACKs, COMETs, INFOs, > and who knows what. Is P1 required to be able to handle all this, and > not send the 482 back to the UAC? Yes. The proxy is suppose to collect the non-2xx final responses, and when it has heard from all the branches and all of them are non-2xx final responses, it sends one non-2xx final response upstream to the UAC. If it had received any 2xx final response(s), which it would send upstream immediately, it does not send any non-2xx upstream. > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 10:39:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04403 for ; Tue, 30 Oct 2001 10:39:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06079 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:39:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04271; Tue, 30 Oct 2001 10:03:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04244 for ; Tue, 30 Oct 2001 10:03:06 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03195 for ; Tue, 30 Oct 2001 10:03:00 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9UF32C22484; Tue, 30 Oct 2001 16:03:02 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9UF31B15005; Tue, 30 Oct 2001 17:03:01 +0200 (EET) Message-ID: <3BDEC11D.BDEC555F@lmf.ericsson.se> Date: Tue, 30 Oct 2001 17:02:53 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: adam.roach@ericsson.com, "'Shan Lu'" , "'Jo Hornsby'" , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> <3BDDECA1.2C1FC4E3@lmf.ericsson.se> <3BDE3DC0.3B5CB4A8@lmf.ericsson.se> <3BDEBF5E.D3DB3A3C@lmf.ericsson.se> <3BDEBEB9.983B7AB@lmf.ericsson.se> <3BDEC43F.41992394@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>It would, though, be good if the branch value in the ACK to the 200 >>could be the same as the branch in the INVITE, so that they could be >>directly matched. >The entity that generates the branch for the ACK does not have to be >and typically is not) the same entity that generated the branch for the >INVITE. That's why ACKs for 2xx responses are slightly different than >ACKs for non-2xx final responses. I know. So, one could argue that the branch parameter shouldn't even be in the Via header - or another header/header value would be used for this. It could be somewhere else, so that the UAC could pick it from the 200 response and use it in the ACK. Regards, Christer Holmberg Ericsson Finland > > Regards, > > Gonzalo > > It would also be more saft, since the UAS doesn't have > > to ASSUME an ACK belongs to the INVITE/200 just because it can't find a > > matching branch value... > > > > Of course, that would require that the branch is generated in some other > > way, and still is unique for each leg, than currently... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > Regards, > > > > > > Gonzalo > > > > > > > And, if the 482 was sent all the way back to P1, or the UAC, and BOTH P1 > > > > and P3 inserted Record-Route, won't we again get the same situation, > > > > because the ACKs will use exactly the same route? > > > > > > > > Someone said that this may not be a real-life case, but I don't agree on > > > > that. And, isn't 3GPP talking about some kind of "inbound" proxy also? > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > Hi, > > > > > > > > > > > Unless, of course, my first assertion was correct (and I do believe > > > > > > that it is): proxies shouldn't merge requests at all, and this > > > > > > should be a UAS issue. > > > > > > > > > > > > > > > > Yes, the one that returns the 482 is the UAS. The only thing a proxy > > > > > does is to compute a different branch in the Via for the requests that > > > > > will be merged by the UAS. > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > /a > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Shan Lu [mailto:shanlu@sentito.com] > > > > > > > Sent: Monday, October 29, 2001 4:11 PM > > > > > > > To: 'Jo Hornsby'; sip@ietf.org > > > > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > > > > differing request > > > > > > > paths. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > > > > > > > Sent: Monday, October 29, 2001 12:21 PM > > > > > > > > To: Shan Lu; sip@ietf.org > > > > > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > > > > > differing request paths. > > > > > > > > > > > > > > > > > > > > > > > > > > Assume that the UAS receives the INVITE from two separate > > > > > > > > "routes". It > > > > > > > > > > sends 200 to the first one, and 482 to the other. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > > > > > > > > > > > > > > > It's important not to get too hung-up on the > > > > > > > > default Reason Phrases. An implementor is > > > > > > > > free to use "Request Merged", or sommat, as > > > > > > > > the Reason Phrase that accompanies the 482. > > > > > > > > 482 is specified by bis-05, and I think > > > > > > > > fits very well semantically with the > > > > > > > > "classical" notion of a 482. > > > > > > > > > > > > > > This sounds like a pretty good reason to define a new cause > > > > > > > code rather > > > > > > > than let everybody come up with their own reason phase. > > > > > > > > > > > > > > > > > > > > > > > > Q2. 200 followd by 4xx works if the paths are due to a > > > > > > > > forking proxy, > > > > > > > > > which will sit there collecting responses and send upstream > > > > > > > > the "best > > > > > > > > > one". Now what if the requests travel different paths because a > > > > > > > > > stateless load balancer distributes requests round robin to > > > > > > > > a farm of > > > > > > > > > proxies and multiple requests end up in the same UAS? In > > > > > > > > this case, both > > > > > > > > > 200 and 4xx are received by the UAC. > > > > > > > > > > > > > > > > This load balancer is broken, then; or, at least, > > > > > > > > the system that it is working in as a whole is > > > > > > > > broken. It should not be possible to observe > > > > > > > > any such behaviour from any other SIP client's / > > > > > > > > server's perspective. > > > > > > > > > > > > > > > > > > > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > > > > > > > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > > > > > > > stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 > > > > > > > which both are sent upstream to UAC. The question is: does > > > > > > > 4xx terminate > > > > > > > the transaction according to 13.2.2.3. > > > > > > > > > > > > > > > > Let's further assume that the UAS > > > > > > > > > responds with 1xx to the first request -- an early dialog > > > > > > > is setup. > > > > > > > > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > > > > > > > > terminate > > > > > > > > > the INVITE transaction, which means the call is dropped. > > > > > > > > And what if the > > > > > > > > > 4xx arrives before 1xx? Does this mean that a load balancer > > > > > > > > here has to > > > > > > > > > be at least transaction stateful? This is also a valid case when > > > > > > > > > different proxies are used for retransmissions. > > > > > > > > > > > > > > > > Retransmissions should always go to the same > > > > > > > > server (proxy). > > > > > > > > > > > > > > In a perfect world, yes. What if the proxy that forwards > > > > > > > initial INVITE > > > > > > > goes down? Let's say its backup (through DNS lookup) has a slightly > > > > > > > different view of the network topology and sends > > > > > > > retransmissions through > > > > > > > a different path. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shan Lu > > > > > > > sentitO Networks > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > > > Columbia University Mobile: +358 40 702 35 35 > > > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > > > New York, NY 10027 > > > > > USA Gonzalo.Camarillo@ericsson.com > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > New York, NY 10027 > > > USA Gonzalo.Camarillo@ericsson.com > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 11:30:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04027 for ; Tue, 30 Oct 2001 10:30:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05274 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 10:30:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03653; Tue, 30 Oct 2001 09:56:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03622 for ; Tue, 30 Oct 2001 09:56:22 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02899 for ; Tue, 30 Oct 2001 09:56:17 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9UEtI017575; Tue, 30 Oct 2001 08:55:18 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9UEtIC02835; Tue, 30 Oct 2001 08:55:18 -0600 (CST) Received: from lmf.ericsson.se (rmt160120.am.ericsson.se [138.85.160.120]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA24914; Tue, 30 Oct 2001 08:55:12 -0600 (CST) Message-ID: <3BDEC43F.41992394@lmf.ericsson.se> Date: Tue, 30 Oct 2001 17:16:15 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: adam.roach@ericsson.com, "'Shan Lu'" , "'Jo Hornsby'" , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> <3BDDECA1.2C1FC4E3@lmf.ericsson.se> <3BDE3DC0.3B5CB4A8@lmf.ericsson.se> <3BDEBF5E.D3DB3A3C@lmf.ericsson.se> <3BDEBEB9.983B7AB@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > It would, though, be good if the branch value in the ACK to the 200 > could be the same as the branch in the INVITE, so that they could be > directly matched. The entity that generates the branch for the ACK does not have to be (and typically is not) the same entity that generated the branch for the INVITE. That's why ACKs for 2xx responses are slightly different than ACKs for non-2xx final responses. Regards, Gonzalo It would also be more saft, since the UAS doesn't have > to ASSUME an ACK belongs to the INVITE/200 just because it can't find a > matching branch value... > > Of course, that would require that the branch is generated in some other > way, and still is unique for each leg, than currently... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Regards, > > > > Gonzalo > > > > > And, if the 482 was sent all the way back to P1, or the UAC, and BOTH P1 > > > and P3 inserted Record-Route, won't we again get the same situation, > > > because the ACKs will use exactly the same route? > > > > > > Someone said that this may not be a real-life case, but I don't agree on > > > that. And, isn't 3GPP talking about some kind of "inbound" proxy also? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > Gonzalo Camarillo wrote: > > > > > > > > Hi, > > > > > > > > > Unless, of course, my first assertion was correct (and I do believe > > > > > that it is): proxies shouldn't merge requests at all, and this > > > > > should be a UAS issue. > > > > > > > > > > > > > Yes, the one that returns the 482 is the UAS. The only thing a proxy > > > > does is to compute a different branch in the Via for the requests that > > > > will be merged by the UAS. > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > > /a > > > > > > > > > > > -----Original Message----- > > > > > > From: Shan Lu [mailto:shanlu@sentito.com] > > > > > > Sent: Monday, October 29, 2001 4:11 PM > > > > > > To: 'Jo Hornsby'; sip@ietf.org > > > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > > > differing request > > > > > > paths. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > > > > > > Sent: Monday, October 29, 2001 12:21 PM > > > > > > > To: Shan Lu; sip@ietf.org > > > > > > > Subject: RE: [Sip] Handling of duplicate requests with > > > > > > > differing request paths. > > > > > > > > > > > > > > > > > > > > > > > Assume that the UAS receives the INVITE from two separate > > > > > > > "routes". It > > > > > > > > > sends 200 to the first one, and 482 to the other. > > > > > > > > > > > > > > > > > > > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > > > > > > > > > > > > > It's important not to get too hung-up on the > > > > > > > default Reason Phrases. An implementor is > > > > > > > free to use "Request Merged", or sommat, as > > > > > > > the Reason Phrase that accompanies the 482. > > > > > > > 482 is specified by bis-05, and I think > > > > > > > fits very well semantically with the > > > > > > > "classical" notion of a 482. > > > > > > > > > > > > This sounds like a pretty good reason to define a new cause > > > > > > code rather > > > > > > than let everybody come up with their own reason phase. > > > > > > > > > > > > > > > > > > > > > Q2. 200 followd by 4xx works if the paths are due to a > > > > > > > forking proxy, > > > > > > > > which will sit there collecting responses and send upstream > > > > > > > the "best > > > > > > > > one". Now what if the requests travel different paths because a > > > > > > > > stateless load balancer distributes requests round robin to > > > > > > > a farm of > > > > > > > > proxies and multiple requests end up in the same UAS? In > > > > > > > this case, both > > > > > > > > 200 and 4xx are received by the UAC. > > > > > > > > > > > > > > This load balancer is broken, then; or, at least, > > > > > > > the system that it is working in as a whole is > > > > > > > broken. It should not be possible to observe > > > > > > > any such behaviour from any other SIP client's / > > > > > > > server's perspective. > > > > > > > > > > > > > > > > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > > > > > > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > > > > > > stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 > > > > > > which both are sent upstream to UAC. The question is: does > > > > > > 4xx terminate > > > > > > the transaction according to 13.2.2.3. > > > > > > > > > > > > > > Let's further assume that the UAS > > > > > > > > responds with 1xx to the first request -- an early dialog > > > > > > is setup. > > > > > > > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > > > > > > > terminate > > > > > > > > the INVITE transaction, which means the call is dropped. > > > > > > > And what if the > > > > > > > > 4xx arrives before 1xx? Does this mean that a load balancer > > > > > > > here has to > > > > > > > > be at least transaction stateful? This is also a valid case when > > > > > > > > different proxies are used for retransmissions. > > > > > > > > > > > > > > Retransmissions should always go to the same > > > > > > > server (proxy). > > > > > > > > > > > > In a perfect world, yes. What if the proxy that forwards > > > > > > initial INVITE > > > > > > goes down? Let's say its backup (through DNS lookup) has a slightly > > > > > > different view of the network topology and sends > > > > > > retransmissions through > > > > > > a different path. > > > > > > > > > > > > > > > > > > > > > > > > Shan Lu > > > > > > sentitO Networks > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > > Columbia University Mobile: +358 40 702 35 35 > > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > > New York, NY 10027 > > > > USA Gonzalo.Camarillo@ericsson.com > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 11:59:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07072 for ; Tue, 30 Oct 2001 11:59:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10115 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 11:59:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07742; Tue, 30 Oct 2001 11:08:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07711 for ; Tue, 30 Oct 2001 11:08:26 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05384 for ; Tue, 30 Oct 2001 11:08:17 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9UG7o000790; Tue, 30 Oct 2001 10:07:50 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9UG7nC21761; Tue, 30 Oct 2001 10:07:49 -0600 (CST) Received: from lmf.ericsson.se (rmt160120.am.ericsson.se [138.85.160.120]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA00974; Tue, 30 Oct 2001 10:07:45 -0600 (CST) Message-ID: <3BDED540.1FD97B7F@lmf.ericsson.se> Date: Tue, 30 Oct 2001 18:28:48 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Bob Penfield , sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: <3BDE40D9.D77E29E3@lmf.ericsson.se> <017c01c1614b$c01c34c0$2300000a@acmepacket.com> <3BDEB6C4.DF72048B@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer, Christer Holmberg wrote: > Yes. I was just worried about cases where it actually may take a > relatively long time before the 200 final response is sent, due to other > call setup actions (PRACK, INFO etc), because I guess the proxy won't > wait "forever" for the final response until it takes some actions (of > course, in a real-life situation the call setup probably won't be that > long) for the pending legs. > The proxy has ACKed already the 482 response. The only thing it does is to store it in a buffer as one of the non-2xx final responses received so far. This way it will be able to choose the "best" one to send back. I do not know why you are raising this now, because this has been standard SIP behavior since the beginning. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 11:59:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07090 for ; Tue, 30 Oct 2001 11:59:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10147 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 11:59:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06896; Tue, 30 Oct 2001 10:56:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06867 for ; Tue, 30 Oct 2001 10:56:48 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04918 for ; Tue, 30 Oct 2001 10:56:39 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9UFugY00533; Tue, 30 Oct 2001 09:56:42 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9UFufj08069; Tue, 30 Oct 2001 09:56:41 -0600 (CST) Received: from lmf.ericsson.se (rmt160120.am.ericsson.se [138.85.160.120]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA29760; Tue, 30 Oct 2001 09:56:37 -0600 (CST) Message-ID: <3BDED2A3.113F9482@lmf.ericsson.se> Date: Tue, 30 Oct 2001 18:17:39 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: IETF SIP Mailing List , Jonathan Rosenberg , "'Shan Lu'" Subject: Re: [Sip] Bis-05 question: CANCEL References: <3BDE5C2A.FF1180BE@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Christer Holmberg wrote: > If the INVITE gets to the UAS AFTER the CANCEL, and starts generating > provisional responses, the UAC can send a new CANCEL. Since the first CANCEL was answered with a 481, its retransmisssions will be also answers with a 481. Basically, if the CANCEL was received before the INVITE, the UAC wouls not have a way to CANCEL the transaction. That's why the UAC has to wait until a 100 Trying is received. > Even if the PROXY does send 100, and the UAC sends CANCEL after that, it > still doesn't mean that the UAS is going to receive the INVITE before > the CANCEL, does it (even if they are using the same route from a SIP > application point of view)? Christer, remember that CANCEL is a hop by hop method. Every proxy in the path waits until it has received the 100 Trying from the next proxy (or from the UAS) before sending the CANCEL. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 14:34:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12505 for ; Tue, 30 Oct 2001 14:34:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16587 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 14:34:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12542; Tue, 30 Oct 2001 12:49:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12510 for ; Tue, 30 Oct 2001 12:49:45 -0500 (EST) Received: from noir.crocodile.org (IDENT:root@w101.z064001167.sjc-ca.dsl.cnc.net [64.1.167.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08824 for ; Tue, 30 Oct 2001 12:49:40 -0500 (EST) Received: from haaretz (dsl-64-128-205-121.telocity.com [64.128.205.121]) by noir.crocodile.org (8.11.6/8.11.6) with SMTP id f9UHneL23535 for ; Tue, 30 Oct 2001 09:49:40 -0800 Message-ID: <069901c1616b$1b25c6a0$0900a8c0@haaretz> From: "Vladimir Vysotsky" To: Date: Tue, 30 Oct 2001 09:48:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Q: hostname sample in bis-05? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It seems to me that one of the URL examples in bis-05 (section 21.1.4, line 3311), namely, sip:alice@%61tlanta.com:5060 contradicts the syntax for the hostname (line 4501) that does not allow escapes in the domainlabel. Which is correct? Vladimir. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 14:41:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12730 for ; Tue, 30 Oct 2001 14:41:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17053 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 14:41:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15577; Tue, 30 Oct 2001 14:09:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15550 for ; Tue, 30 Oct 2001 14:09:15 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11707 for ; Tue, 30 Oct 2001 14:09:11 -0500 (EST) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f9UJFJD14960 for ; Tue, 30 Oct 2001 13:15:19 -0600 Message-ID: <014e01c16176$56127550$ad036e3f@flak> From: "Dean Willis" To: References: Date: Tue, 30 Oct 2001 13:09:00 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Rewriting the Request-URI -- Considered Harmful? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Much of the bis-05 disucssion has been around handling of record-routes, outbound proxies, and which nodes update the request-URI for routing purposes, and when they do so. Occasionally we also speculate on how this will interact with proposed loose routing. This is probably one of the most confusing issues in SIP. I've seen many conflicting approaches, including 3GPP discussions that implement local routing policy by inserting a new Route (not derived from a Record-Route) and replacing the request-URI. This has to stop -- it makes my head hurt. I'd like to propose that we consider two approaches: 1) ALWAYS replace the request-URI, even for local outbound proxy applications. We might use the 3GPP approach and put the original request-URI in a Route header, then put the host of the local outbound proxy into the request-URI. In essence, this implements a route-stack, with the request-URI being the top of the stack. 2) NEVER replace the request-URI, as proposed in the loose-routing discssion. Just pop the route header and send the request to the destination described by the popped Route. This also provides a route-stack, with the topmost Route header being the top of the stack, and the request-URI not being referenced until the route stack is exhausted. Personally, I'd vote for number 2: I think the only time the request-URI should change is when the request is being retargetted as a result of application logic. Think of IP routing -- the destination address of a packet doesn't change just because the packet was processed by an intermediary router. Or SMTP routing -- the Rcpt To: email address doesn't change as the message is propagated from server to server. Of course, we'd need to consider the backward-compatibility implications. I haven't thought this all the way through, but I don't think either approach is trivial to resolve. My hunch is that approach number 1 might be closer to compatible. -- Dean _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 15:53:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14120 for ; Tue, 30 Oct 2001 15:53:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19085 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 15:53:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18357; Tue, 30 Oct 2001 15:17:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18330 for ; Tue, 30 Oct 2001 15:17:51 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13425 for ; Tue, 30 Oct 2001 15:17:47 -0500 (EST) Received: (qmail 16302 invoked from network); 30 Oct 2001 20:10:34 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 30 Oct 2001 20:10:34 -0000 From: "Shan Lu" To: "'Gonzalo Camarillo'" , "'Christer Holmberg'" Cc: "'IETF SIP Mailing List'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Tue, 30 Oct 2001 15:17:10 -0500 Message-ID: <000201c1617f$daed2500$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BDED2A3.113F9482@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Tuesday, October 30, 2001 11:18 AM > To: Christer Holmberg > Cc: IETF SIP Mailing List; Jonathan Rosenberg; 'Shan Lu' > Subject: Re: [Sip] Bis-05 question: CANCEL > > > Hello, > > Christer Holmberg wrote: > > > If the INVITE gets to the UAS AFTER the CANCEL, and starts > generating > > provisional responses, the UAC can send a new CANCEL. > > Since the first CANCEL was answered with a 481, its retransmisssions > will be also answers with a 481. I don't think it's a retransmission. It's going to be a NEW CANCEL (cseq.num++). >Basically, if the CANCEL was received > before the INVITE, the UAC wouls not have a way to CANCEL the > transaction. That's why the UAC has to wait until a 100 Trying is > received. > If you want to wait for 1xx from UAS, you run the danger of waiting a bit too long. 1xx might just get lost and the next thing you will see is 200 OK. This effectively renders the CANCEL useless. So wait or not to wait, you have the same risk of nullifying CANCEL. I don't think one risk is bigger than the other. And not to wait is obvious simple and clean. Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 15:56:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14204 for ; Tue, 30 Oct 2001 15:56:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19121 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 15:57:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18861; Tue, 30 Oct 2001 15:33:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18828 for ; Tue, 30 Oct 2001 15:33:38 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13749 for ; Tue, 30 Oct 2001 15:33:34 -0500 (EST) Received: (qmail 17381 invoked from network); 30 Oct 2001 20:26:23 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 30 Oct 2001 20:26:23 -0000 From: "Shan Lu" To: "IETF SIP Mailing List" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Tue, 30 Oct 2001 15:32:58 -0500 Message-ID: <000301c16182$100a5580$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > I don't think it's a retransmission. It's going to be a NEW > CANCEL (cseq.num++). > This is obviously wrong. Disregard the comment. Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 17:19:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15996 for ; Tue, 30 Oct 2001 17:19:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21352 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 17:19:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19958; Tue, 30 Oct 2001 16:27:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19931 for ; Tue, 30 Oct 2001 16:27:35 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14993 for ; Tue, 30 Oct 2001 16:27:30 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9ULQV007737; Tue, 30 Oct 2001 15:26:31 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9ULQVj07214; Tue, 30 Oct 2001 15:26:31 -0600 (CST) Received: from lmf.ericsson.se (rmt160161.am.ericsson.se [138.85.160.161]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA28003; Tue, 30 Oct 2001 15:26:29 -0600 (CST) Message-ID: <3BDF1FF2.F6C31A7D@lmf.ericsson.se> Date: Tue, 30 Oct 2001 23:47:30 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shan Lu CC: "'Christer Holmberg'" , "'IETF SIP Mailing List'" , "'Jonathan Rosenberg'" Subject: Re: [Sip] Bis-05 question: CANCEL References: <000201c1617f$daed2500$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Gonzalo wrote: > > Since the first CANCEL was answered with a 481, its retransmisssions > > will be also answers with a 481. > > I don't think it's a retransmission. It's going to be a NEW CANCEL > (cseq.num++). You should read how CANCEL works in SIP. The CANCEL request has always the same Cseq as the request being cancelled. > >Basically, if the CANCEL was received > > before the INVITE, the UAC wouls not have a way to CANCEL the > > transaction. That's why the UAC has to wait until a 100 Trying is > > received. > > > > If you want to wait for 1xx from UAS, you run the danger of waiting a > bit too long. 1xx might just get lost and the next thing you will see is > 200 OK. This effectively renders the CANCEL useless. > If the 100 Trying gets lost you will be retransmitting the INVITE until you get it. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 17:20:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16028 for ; Tue, 30 Oct 2001 17:19:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21369 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 17:20:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20451; Tue, 30 Oct 2001 16:38:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20419 for ; Tue, 30 Oct 2001 16:38:37 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15315 for ; Tue, 30 Oct 2001 16:38:32 -0500 (EST) Received: (qmail 22193 invoked from network); 30 Oct 2001 21:31:21 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 30 Oct 2001 21:31:21 -0000 From: "Shan Lu" To: "'Gonzalo Camarillo'" Cc: "'Christer Holmberg'" , "'IETF SIP Mailing List'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Tue, 30 Oct 2001 16:37:57 -0500 Message-ID: <000401c1618b$23e5dda0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BDF1FF2.F6C31A7D@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > You should read how CANCEL works in SIP. The CANCEL request has always > the same Cseq as the request being cancelled. > So noted. > > >Basically, if the CANCEL was received > > > before the INVITE, the UAC wouls not have a way to CANCEL the > > > transaction. That's why the UAC has to wait until a 100 Trying is > > > received. > > > > > > > If you want to wait for 1xx from UAS, you run the danger of > waiting a > > bit too long. 1xx might just get lost and the next thing > you will see is > > 200 OK. This effectively renders the CANCEL useless. > > > > If the 100 Trying gets lost you will be retransmitting the > INVITE until > you get it. > Nobody disputes this. But the point here is that a loss or delay of 1xx may render the CANCEL useless. Regards, Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 17:36:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16363 for ; Tue, 30 Oct 2001 17:36:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21907 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 17:36:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21132; Tue, 30 Oct 2001 17:02:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21101 for ; Tue, 30 Oct 2001 17:01:58 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15757 for ; Tue, 30 Oct 2001 17:01:53 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9UM1tY19795; Tue, 30 Oct 2001 16:01:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9UM1sC12925; Tue, 30 Oct 2001 16:01:54 -0600 (CST) Received: from lmf.ericsson.se (rmt160161.am.ericsson.se [138.85.160.161]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA00154; Tue, 30 Oct 2001 16:01:52 -0600 (CST) Message-ID: <3BDF283E.A8AA69CA@lmf.ericsson.se> Date: Wed, 31 Oct 2001 00:22:54 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shan Lu CC: "'Christer Holmberg'" , "'IETF SIP Mailing List'" , "'Jonathan Rosenberg'" Subject: Re: [Sip] Bis-05 question: CANCEL References: <000401c1618b$23e5dda0$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Shan Lu wrote: > > Nobody disputes this. But the point here is that a loss or delay of 1xx > may render the CANCEL useless. As I stated previously, if the CANCEL arrives to the server before the INVITE, the UAC will not have any way to cancel the request. Then it would have to wait until the INVITE is answered in order to send a BYE... and this can really take very long. Therefore, we have to avoid that situation. In order to do that, we can either buffer at the client side or at the server side. TCP, for instance, buffers at the server side. However, we have decided to buffer at the client side because doing so at the server side creates potential DoS attacks. Upon reception of an out of the blue CANCEL a server might have to store state waiting for the matching INVITE. Since this is unacceptable, the only solution is the one proposed in bis-05. I hope this clarifies everything realted to this issue. Regards. Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 18:32:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17069 for ; Tue, 30 Oct 2001 18:32:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22959 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 18:32:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22462; Tue, 30 Oct 2001 18:05:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22432 for ; Tue, 30 Oct 2001 18:05:23 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16779 for ; Tue, 30 Oct 2001 18:04:40 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9UN2qb7013473; Tue, 30 Oct 2001 18:02:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Oct 2001 18:04:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E735@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Vladimir Vysotsky'" , sip@ietf.org Subject: RE: [Sip] Q: hostname sample in bis-05? Date: Tue, 30 Oct 2001 18:04:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="koi8-r" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Right now, the BNF wins. I'll change the example to show escaping in the user field instead. This brings up an interesting question though - should we move to allow escaping in hostname? If we make that move now, we get extra complexity for little to no gain. However, as IDN becomes more real, we're going to have to do something like it (and I think escaping across UTF-8 will give us everything we'd need). RjS > -----Original Message----- > From: Vladimir Vysotsky [mailto:trivee@noir.crocodile.org] > Sent: Tuesday, October 30, 2001 11:49 AM > To: sip@ietf.org > Subject: [Sip] Q: hostname sample in bis-05? > > > It seems to me that one of the URL examples in bis-05 > (section 21.1.4, line > 3311), namely, > > sip:alice@%61tlanta.com:5060 > > contradicts the syntax for the hostname (line 4501) that does > not allow > escapes in the domainlabel. Which is correct? > > Vladimir. > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 18:33:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17086 for ; Tue, 30 Oct 2001 18:33:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22973 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 18:33:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22540; Tue, 30 Oct 2001 18:07:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22507 for ; Tue, 30 Oct 2001 18:07:01 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16805 for ; Tue, 30 Oct 2001 18:06:55 -0500 (EST) Received: (qmail 28778 invoked from network); 30 Oct 2001 22:59:44 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 30 Oct 2001 22:59:44 -0000 From: "Shan Lu" To: "'Gonzalo Camarillo'" Cc: "'Christer Holmberg'" , "'IETF SIP Mailing List'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Tue, 30 Oct 2001 18:06:20 -0500 Message-ID: <000001c16197$7cd62710$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BDF283E.A8AA69CA@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, October 30, 2001 5:23 PM > To: Shan Lu > Cc: 'Christer Holmberg'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg' > Subject: Re: [Sip] Bis-05 question: CANCEL > > > Hello, > > Shan Lu wrote: > > > > > Nobody disputes this. But the point here is that a loss or > delay of 1xx > > may render the CANCEL useless. > > As I stated previously, if the CANCEL arrives to the server before the > INVITE, the UAC will not have any way to cancel the request. Then it > would have to wait until the INVITE is answered in order to send a > BYE... and this can really take very long. Why can't BYE be sent for an early dialog to terminate the dialog? Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 19:57:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17966 for ; Tue, 30 Oct 2001 19:57:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA24120 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 19:58:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23501; Tue, 30 Oct 2001 19:17:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23470 for ; Tue, 30 Oct 2001 19:17:38 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17526 for ; Tue, 30 Oct 2001 19:17:35 -0500 (EST) From: Jin-Gen.Wang@level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id AAA17616 for ; Wed, 31 Oct 2001 00:17:37 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id AAA06527 for ; Wed, 31 Oct 2001 00:17:37 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <4GXRRGQG>; Tue, 30 Oct 2001 17:17:36 -0700 Message-ID: To: sip@ietf.org Date: Tue, 30 Oct 2001 17:12:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] question on "Route" header examples (bis-05) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think the "Route" header examples shown in section 7.3.1 (line 768 to line 788) are not in valid format based on rules in section 26.1 (page 136, line 4547). The field value should be in name-addr format which always has "<" and ">". Somebody please clarify on this. Thanks. Jin-Gen Wang Level 3 Communications, Inc. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 19:58:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17983 for ; Tue, 30 Oct 2001 19:58:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA24136 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 19:58:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24033; Tue, 30 Oct 2001 19:44:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24002 for ; Tue, 30 Oct 2001 19:44:19 -0500 (EST) Received: from brmx1.fl.icn.siemens.com ([12.147.96.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17825 for ; Tue, 30 Oct 2001 19:44:16 -0500 (EST) Received: from boca210a.lm.ssc.siemens.com (boca210a.boca.ssc.siemens.com [165.218.12.110]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id TAA01792; Tue, 30 Oct 2001 19:32:35 -0500 (EST) Received: by boca210a.boca.ssc.siemens.com with Internet Mail Service (5.5.2653.19) id <4QVQYQ4A>; Tue, 30 Oct 2001 19:35:26 -0500 Message-ID: From: "Karapetkov, Stefan H" To: "'Ralf Ackermann'" , sip@ietf.org Cc: rac@iptel-now.de, sip-implementors@cs.columbia.edu, support@pingtel.com, info@vovida.org Subject: RE: [Sip] Q: SIP support in MS XP Messenger? Date: Tue, 30 Oct 2001 19:34:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ralf, at the WinXP launch last week, we demonstrated interoperability between the Siemens optiPoint 100 advance SIP telephones and the Windows XP RTC client (Phoenix) as well as between the SIP phone and the Ubiquity SIP soft client that runs on the Messenger API. The Messenger application itself is not released yet but since it uses the same SIP stack, we expect 100% interoperability. Regards, Stefan Stefan Karapetkov Product Line Manager IP Telephones Siemens Enterprise Networks Phone (408) 492 6044 Mobile (408) 887 7092 Fax (408) 492 2902 Email kara@icn.siemens.com IP Telephones Information at http://www.siemensenterprise.com/current/desktops/ -----Original Message----- From: Ralf Ackermann [mailto:rac@kom.tu-darmstadt.de] Sent: Tuesday, October 30, 2001 1:35 AM To: sip@ietf.org Cc: rac@iptel-now.de; sip-implementors@cs.columbia.edu; support@pingtel.com; info@vovida.org Subject: [Sip] Q: SIP support in MS XP Messenger? Hello, i have a question on the status of support for SIP in the Microsoft XP Messenger. Since MS claims this product uses SIP (for e.g. placing audio calls but also Instant Messaging) - has anybody tested, whether - Microsoft XP Messenger (most recent version is 4.5) interoperates with SIP infrastructure components (e.g. sipd from Columbia University) ? - Microsoft XP Messenger interoperates with any SIP soft- or hardphones (e.g. Pingtel xpressa, VOCAL UA ...)? Any hints/experiences are highly appreciated (since we didn't identify configuration options / "hooks" that indicate such support yet). Best regards ralf -- Best regards, Ralf Ackermann --------------------------------------------------------------- Hosting the IP Telephony Field Trial for the Darmstadt Region --------------------------------------------------------------- Ralf Ackermann _ rac@KOM.tu-darmstadt.de Industrial Process and |/ | | |\/| Merckstrasse 25 System Communications |\ |_| | | 64283 Darmstadt, Germany Tel.: (+49) 6151 16-6138 Fax: (+49) 6151 16-6152 --------------------------------------------------------------- http://www.kom.e-technik.tu-darmstadt.de/~rac --------------------------------------------------------------- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Oct 30 20:36:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18360 for ; Tue, 30 Oct 2001 20:36:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA25178 for sip-archive@odin.ietf.org; Tue, 30 Oct 2001 20:35:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24628; Tue, 30 Oct 2001 20:15:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24597 for ; Tue, 30 Oct 2001 20:15:49 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18149 for ; Tue, 30 Oct 2001 20:15:46 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id f9V1FXV07374; Tue, 30 Oct 2001 20:15:33 -0500 (EST) Message-ID: <3BDF50B5.75E6285D@cs.columbia.edu> Date: Tue, 30 Oct 2001 20:15:33 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: "'Vladimir Vysotsky'" , sip@ietf.org Subject: Re: [Sip] Q: hostname sample in bis-05? References: <9BF66EBF6BEFD942915B4D4D45C051F338E735@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > Right now, the BNF wins. > I'll change the example to show escaping in the user field instead. > > This brings up an interesting question though - should we move to > allow escaping in hostname? > > If we make that move now, we get extra complexity for little to no gain. > > However, as IDN becomes more real, we're going to have to do > something like it (and I think escaping across UTF-8 will give us > everything we'd need). The expired draft http://www.w3.org/International/2000/03/draft-masinter-url-i18n-05.txt describes the process in detail, but explicitly excludes host names. However, I doubt that putting ACE in URIs is the right approach, either. I doubt that the complexity is high, since you're doing escaping and unescaping for all the other parts. > > RjS > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 01:06:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23064 for ; Wed, 31 Oct 2001 01:06:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA01027 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 01:06:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29180; Wed, 31 Oct 2001 00:40:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29149 for ; Wed, 31 Oct 2001 00:40:36 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22774 for ; Wed, 31 Oct 2001 00:40:29 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9V5eQC27302; Wed, 31 Oct 2001 06:40:27 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9V5eQB00732; Wed, 31 Oct 2001 07:40:26 +0200 (EET) Message-ID: <3BDF8EBF.8830C80A@lmf.ericsson.se> Date: Wed, 31 Oct 2001 07:40:15 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shan Lu CC: "'Gonzalo Camarillo'" , "'IETF SIP Mailing List'" , "'Jonathan Rosenberg'" Subject: Re: [Sip] Bis-05 question: CANCEL References: <000001c16197$7cd62710$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I understand the arguments for buffering. BUT, by waiting for the first 1xx we still don't solve the CANCEL/200 race condition. Also, consider the following case: |------- UAS 1 UAC --- P1 |------- UAS 2 Now, the UAC sends an INVITE, which gets forked by P1. P1 also sends 100 back to UAC. Then, the UAC decides to terminate the setup, so it sends CANCEL. Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL there. HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do that. Instead, the UAS 2 returns 200 OK immedeately. So, what does P1 do now? Creates a BYE transaction to UAS 2 - and when it receives a response to that it sends 200 for the CANCEL to the UAC??? This sounds a little like B2BUA behaviour to me... AND, the following (easier case) could also have happened in the scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when P1 sends a CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? 1. Create a BYE to both UAS 1 and UAS 2? 2. Forward the 200 response for the INVITE to the UAC, and sends 487 for the CANCEL to the UAC? >>As I stated previously, if the CANCEL arrives to the server before the >>INVITE, the UAC will not have any way to cancel the request. Then it >>would have to wait until the INVITE is answered in order to send a >>BYE... and this can really take very long. >Why can't BYE be sent for an early dialog to terminate the dialog? This has been discussed before, and the UAC CAN use BYE to terminate a dialog, assuming it has received a 1xx with a To header tag. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 01:06:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23078 for ; Wed, 31 Oct 2001 01:06:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA01141 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 01:06:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29279; Wed, 31 Oct 2001 00:46:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29250 for ; Wed, 31 Oct 2001 00:46:31 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22796 for ; Wed, 31 Oct 2001 00:46:27 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9V5kSf24097 for ; Wed, 31 Oct 2001 06:46:28 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9V5kSB00856 for ; Wed, 31 Oct 2001 07:46:28 +0200 (EET) Message-ID: <3BDF9028.C74493F1@lmf.ericsson.se> Date: Wed, 31 Oct 2001 07:46:16 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Removal proposal: Password in SIP-URL Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The bis recommends that the password of the SIP-URL user part is not to be used. My question is: in this case, can't we remove it completely? OR, is there anyone who really uses it? In future, if someone wants to send passwords in SIP messages, a specific header (and maybe also even an option-tag) could be used for that. Comments? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 01:42:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27946 for ; Wed, 31 Oct 2001 01:42:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA07592 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 01:42:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29230; Wed, 31 Oct 2001 00:43:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29201 for ; Wed, 31 Oct 2001 00:43:03 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22786 for ; Wed, 31 Oct 2001 00:42:59 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9V5h0C27522; Wed, 31 Oct 2001 06:43:00 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9V5h0B00809; Wed, 31 Oct 2001 07:43:00 +0200 (EET) Message-ID: <3BDF8F58.B231B4E1@lmf.ericsson.se> Date: Wed, 31 Oct 2001 07:42:48 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Bob Penfield , sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: <3BDE40D9.D77E29E3@lmf.ericsson.se> <017c01c1614b$c01c34c0$2300000a@acmepacket.com> <3BDEB6C4.DF72048B@lmf.ericsson.se> <3BDED540.1FD97B7F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Yes. I was just worried about cases where it actually may take a >>relatively long time before the 200 final response is sent, due to other >>call setup actions (PRACK, INFO etc), because I guess the proxy won't >>wait "forever" for the final response until it takes some actions (of >>course, in a real-life situation the call setup probably won't be that >>long) for the pending legs. >> > >The proxy has ACKed already the 482 response. The only thing it does is >to store it in a buffer as one of the non-2xx final responses received >so far. This way it will be able to choose the "best" one to send back. > >I do not know why you are raising this now, because this has been >standard SIP behavior since the beginning. I just wanted to clarify the specific case where it takes a long time before the final response is received for a specific leg, because the use of call pre-setup transactions etc has NOT been standard SIP behavious since the beginning... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 01:43:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28034 for ; Wed, 31 Oct 2001 01:43:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA07609 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 01:43:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07195; Wed, 31 Oct 2001 01:26:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07164 for ; Wed, 31 Oct 2001 01:26:31 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25688 for ; Wed, 31 Oct 2001 01:26:23 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9V6QPC02951; Wed, 31 Oct 2001 07:26:25 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9V6QOB01780; Wed, 31 Oct 2001 08:26:24 +0200 (EET) Message-ID: <3BDF9985.5B66B21E@lmf.ericsson.se> Date: Wed, 31 Oct 2001 08:26:13 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo , Bob Penfield , sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: <3BDE40D9.D77E29E3@lmf.ericsson.se> <017c01c1614b$c01c34c0$2300000a@acmepacket.com> <3BDEB6C4.DF72048B@lmf.ericsson.se> <3BDED540.1FD97B7F@lmf.ericsson.se> <3BDF8F58.B231B4E1@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Just one more clarification related to this: The proxy forks an INVITE. Then it receives 482 for one leg, and waits for the final responses also from the other legs. My question is: even if the proxy waits for the final responses, it still DOES forward PROVISIONAL responses to the UAC, right? Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > > Hi, > > >>Yes. I was just worried about cases where it actually may take a > >>relatively long time before the 200 final response is sent, due to other > >>call setup actions (PRACK, INFO etc), because I guess the proxy won't > >>wait "forever" for the final response until it takes some actions (of > >>course, in a real-life situation the call setup probably won't be that > >>long) for the pending legs. > >> > > > >The proxy has ACKed already the 482 response. The only thing it does is > >to store it in a buffer as one of the non-2xx final responses received > >so far. This way it will be able to choose the "best" one to send back. > > > >I do not know why you are raising this now, because this has been > >standard SIP behavior since the beginning. > > I just wanted to clarify the specific case where it takes a long time > before the final response is received for a specific leg, because the > use of call pre-setup transactions etc has NOT been standard SIP > behavious since the beginning... > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 02:47:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08524 for ; Wed, 31 Oct 2001 02:47:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA08512 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 02:47:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08060; Wed, 31 Oct 2001 02:18:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08029 for ; Wed, 31 Oct 2001 02:18:48 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08337 for ; Wed, 31 Oct 2001 02:18:45 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9V7GJf02550 for ; Wed, 31 Oct 2001 08:16:19 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9V7GIB03302 for ; Wed, 31 Oct 2001 09:16:18 +0200 (EET) Message-ID: <3BDFA537.25EAC9B7@lmf.ericsson.se> Date: Wed, 31 Oct 2001 09:16:07 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Another proxy-waiting-for-final-response case Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Consider the following scenario: |------- UAS 1 | UAC --- P1------- UAS 2 | |------- UAS 3 Then: 1. UAC sends an INVITE, which gets forked to UAS 1, 2 and 3. 2. UAS 1 sends an 4xx response, which P1 "collects". 3. UAS 2 and UAS 3 both send 18x provisional responses (including To header tags), which are forwarded by P1 to the UAC. 4. The UAC wants to terminate the leg with UAS 3, so it sends BYE. 5. UAS 3 sends 200 for the BYE and 487 for the INVITE. Now, P1 forwards the 200 to the UAC, but it "collects" the 487. 6. UAS 2 sends 200 for the INVITE, and P1 now forwards that to the UAC, and the call is established. I guess this all works fine, but the point I want to make is that the UAC will never receive a 487 for the leg it terminated. Or? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 05:56:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09855 for ; Wed, 31 Oct 2001 05:56:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12409 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 05:56:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12284; Wed, 31 Oct 2001 05:47:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12193 for ; Wed, 31 Oct 2001 05:47:03 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09785 for ; Wed, 31 Oct 2001 05:46:56 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 02:47:11 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Christer Holmberg'" , Gonzalo Camarillo Cc: Bob Penfield , sip@ietf.org Subject: RE: [Sip] 482 handling by proxies Date: Wed, 31 Oct 2001 02:47:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > >>Yes. I was just worried about cases where it actually may take a > >>relatively long time before the 200 final response is sent, > due to other > >>call setup actions (PRACK, INFO etc), because I guess the > proxy won't > >>wait "forever" for the final response until it takes some > actions (of > >>course, in a real-life situation the call setup probably > won't be that > >>long) for the pending legs. > >> > > > >The proxy has ACKed already the 482 response. The only thing > it does is > >to store it in a buffer as one of the non-2xx final > responses received > >so far. This way it will be able to choose the "best" one to > send back. > > > >I do not know why you are raising this now, because this has been > >standard SIP behavior since the beginning. > > I just wanted to clarify the specific case where it takes a long time > before the final response is received for a specific leg, because the > use of call pre-setup transactions etc has NOT been standard SIP > behavious since the beginning... > Christer, There are two alternatives: When a proxy forks a request it slaps on a proxy-selected "No-Answer Timeout" on INVITE requests, that is, a proxy will wait around for a certain time for final responses from all branches and otherwise it will just return the best non-2xx response received and CANCEL out other branches. Imposing local timers that affect answer timeouts is a bad thing !! The other alternative is that the proxy "never" times outs and will only send a final response when _all_ branches have responded with a non-2xx response (assuming that a 1xx has been received from each branch) OR one branch has returned a 2xx response OR the caller CANCEL's. It is obvious that proxies must protect themselves from stale state and so the obvious conclusion from this is that a timeout should be used but the timeout should not affect the normal "Answer Timeout" of a call. The draft should recommend an appropriate minimum value - probably on the order of a few hours or even more (it should be remembered that this is a timeout on the proxy and not the UA devices). Very long "ring" times can have their uses. Robert. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 06:00:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09905 for ; Wed, 31 Oct 2001 06:00:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA12723 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 06:00:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12067; Wed, 31 Oct 2001 05:37:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12033 for ; Wed, 31 Oct 2001 05:37:35 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09699 for ; Wed, 31 Oct 2001 05:37:32 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VAbZC00761; Wed, 31 Oct 2001 11:37:35 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VAbYB12314; Wed, 31 Oct 2001 12:37:34 +0200 (EET) Message-ID: <3BDFD462.B5F5A170@lmf.ericsson.se> Date: Wed, 31 Oct 2001 12:37:22 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo , Bob Penfield , sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: <3BDE40D9.D77E29E3@lmf.ericsson.se> <017c01c1614b$c01c34c0$2300000a@acmepacket.com> <3BDEB6C4.DF72048B@lmf.ericsson.se> <3BDED540.1FD97B7F@lmf.ericsson.se> <3BDF8F58.B231B4E1@lmf.ericsson.se> <3BDF9985.5B66B21E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I found the answer to this one in the new bis (page 83), so case is closed :) Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > > Hi, > > Just one more clarification related to this: > > The proxy forks an INVITE. Then it receives 482 for one leg, and waits > for the final responses also from the other legs. > > My question is: even if the proxy waits for the final responses, it > still DOES forward PROVISIONAL responses to the UAC, right? > > Regards, > > Christer Holmberg > Ericsson Finland > > Christer Holmberg wrote: > > > > Hi, > > > > >>Yes. I was just worried about cases where it actually may take a > > >>relatively long time before the 200 final response is sent, due to other > > >>call setup actions (PRACK, INFO etc), because I guess the proxy won't > > >>wait "forever" for the final response until it takes some actions (of > > >>course, in a real-life situation the call setup probably won't be that > > >>long) for the pending legs. > > >> > > > > > >The proxy has ACKed already the 482 response. The only thing it does is > > >to store it in a buffer as one of the non-2xx final responses received > > >so far. This way it will be able to choose the "best" one to send back. > > > > > >I do not know why you are raising this now, because this has been > > >standard SIP behavior since the beginning. > > > > I just wanted to clarify the specific case where it takes a long time > > before the final response is received for a specific leg, because the > > use of call pre-setup transactions etc has NOT been standard SIP > > behavious since the beginning... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 06:09:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09958 for ; Wed, 31 Oct 2001 06:09:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA12812 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 06:09:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12383; Wed, 31 Oct 2001 05:53:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12354 for ; Wed, 31 Oct 2001 05:53:21 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09845 for ; Wed, 31 Oct 2001 05:53:17 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VArJC07130; Wed, 31 Oct 2001 11:53:19 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VArIB12908; Wed, 31 Oct 2001 12:53:18 +0200 (EET) Message-ID: <3BDFD812.F34F2112@lmf.ericsson.se> Date: Wed, 31 Oct 2001 12:53:06 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo , adam.roach@ericsson.com, "'Shan Lu'" , "'Jo Hornsby'" , sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> <3BDDECA1.2C1FC4E3@lmf.ericsson.se> <3BDE3DC0.3B5CB4A8@lmf.ericsson.se> <3BDEBF5E.D3DB3A3C@lmf.ericsson.se> <3BDEBEB9.983B7AB@lmf.ericsson.se> <3BDEC43F.41992394@lmf.ericsson.se> <3BDEC11D.BDEC555F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>>It would, though, be good if the branch value in the ACK to the 200 >>>could be the same as the branch in the INVITE, so that they could be >>>directly matched. >>The entity that generates the branch for the ACK does not have to be >>and typically is not) the same entity that generated the branch for the >>INVITE. That's why ACKs for 2xx responses are slightly different than >>ACKs for non-2xx final responses. >I know. So, one could argue that the branch parameter shouldn't even be >in the Via header - or another header/header value would be used for >this. It could be somewhere else, so that the UAC could pick it from the >200 response and use it in the ACK. I wonder if we could define some kind of "branch-tag" for this (as a To header parameter, for example), which the UAS could insert in the final responses to the INVITEs - or at least in the 200 response. The UAC could then copy it to the ACK request, and it would then be used by the UAS to match the ACK to the INVITE which generated the 200. Of course, the use of the tag would be optional, and if either party doesn't support it the old mechanism would simply be used, ie assuming that an ACK belongs to the INVITE which generated the 200 because the Via branch value in the ACK doesn't match any value in the UAS. Comments? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 06:38:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10343 for ; Wed, 31 Oct 2001 06:38:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13854 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 06:38:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13117; Wed, 31 Oct 2001 06:20:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13088 for ; Wed, 31 Oct 2001 06:20:47 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10072 for ; Wed, 31 Oct 2001 06:20:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VBKlC18727; Wed, 31 Oct 2001 12:20:47 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VBKkB13910; Wed, 31 Oct 2001 13:20:46 +0200 (EET) Message-ID: <3BDFDE82.DE6A6D3E@lmf.ericsson.se> Date: Wed, 31 Oct 2001 13:20:34 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: Gonzalo Camarillo , Bob Penfield , sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Robert, >>I just wanted to clarify the specific case where it takes a long time >>before the final response is received for a specific leg, because the >>use of call pre-setup transactions etc has NOT been standard SIP >>behavious since the beginning... >> > >Christer, > >There are two alternatives: > >When a proxy forks a request it slaps on a proxy-selected "No-Answer >Timeout" on INVITE requests, that is, a proxy will wait around for a certain >time for final responses from all branches and otherwise it will just return >the best non-2xx response received and CANCEL out other branches. >Imposing local timers that affect answer timeouts is a bad thing !! Agree. >The other alternative is that the proxy "never" times outs and will only >send a final response when _all_ branches have responded with a non-2xx >response (assuming that a 1xx has been received from each branch) OR one >branch has returned a 2xx response OR the caller CANCEL's. > >It is obvious that proxies must protect themselves from stale state and so >the obvious conclusion from this is that a timeout should be used but the >timeout should not affect the normal "Answer Timeout" of a call. The draft >should recommend an appropriate minimum value - probably on the order of a >few hours or even more (it should be remembered that this is a timeout on >the proxy and not the UA devices). > >Very long "ring" times can have their uses. Yes. This is affects the C timer (the time a client waits for a final response after it has received a provisional response). If an INVITE is sent, and a provisional response is received, the C timer should also be long enough so that the client will remain in the "proceeding state" (as defined on page 94) long enough for all the other pre call setup transactions to take place. A couple of questions related to the C timer: 1. Is if for the whole call setup, or per early leg? Ie, the UAC may receive provisional responses from two separate UAS, but at some state the C timer expires for one leg. Does the UAC then terminate that specific leg? 2. Is the C timer set to zero every time a new provisional response is received? IF so, again, is it set to zero for the whole call setup, or only for that specific early leg? Regards, Christer Holmberg Ericsson Finland > > Robert. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 08:35:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17435 for ; Wed, 31 Oct 2001 08:35:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16789 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 08:35:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16183; Wed, 31 Oct 2001 08:15:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16154 for ; Wed, 31 Oct 2001 08:15:24 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16466 for ; Wed, 31 Oct 2001 08:15:24 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA25262; Wed, 31 Oct 2001 08:15:26 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id f9VDFQ614117; Wed, 31 Oct 2001 08:15:26 -0500 (EST) Message-ID: <3BDFF9CD.5436DE1A@cs.columbia.edu> Date: Wed, 31 Oct 2001 08:17:01 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Removal proposal: Password in SIP-URL References: <3BDF9028.C74493F1@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit If my recollection is correct, this suggestion has been discussed before, at least once, and been rejected. Apparently, people do implement it; the cost is essentially zero. (A header wouldn't add any security benefit, but would make including the password, e.g., for a SIP URL on a secure, private web page for friends, much more painful and prone to errors.) Christer Holmberg wrote: > > Hi, > > The bis recommends that the password of the SIP-URL user part is not to > be used. > > My question is: in this case, can't we remove it completely? OR, is > there anyone who really uses it? > > In future, if someone wants to send passwords in SIP messages, a > specific header (and maybe also even an option-tag) could be used for > that. > > Comments? > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 08:36:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17548 for ; Wed, 31 Oct 2001 08:36:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16810 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 08:36:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16252; Wed, 31 Oct 2001 08:18:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16221 for ; Wed, 31 Oct 2001 08:18:55 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16612 for ; Wed, 31 Oct 2001 08:18:55 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 31 Oct 2001 13:19:03 UT Received: from jhornsby ([193.195.52.40]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 31 Oct 2001 13:20:56 +0000 From: "Jo Hornsby" To: "Shan Lu" , Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Wed, 31 Oct 2001 13:18:58 -0000 Message-ID: <000701c1620e$99311740$2834c3c1@eu.ubiquity.net> 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 In-Reply-To: <001601c160c6$8f239730$eb00000a@SAJAK> X-OriginalArrivalTime: 31 Oct 2001 13:20:56.0903 (UTC) FILETIME=[DFED7570:01C1620E] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > This load balancer is broken, then; or, at least, > > the system that it is working in as a whole is > > broken. It should not be possible to observe > > any such behaviour from any other SIP client's / > > server's perspective. > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > stateless load balancer. Uh. Maybe there is nothing wrong with the "stateless load balancer" (I don't know what its mandate is), but it certainly represents no entity that I am aware of in the spec, and thus will break the network if the "proxy"s behind it are not aware that there is a "stateless load balancer" serving them. What I'm saying is that this load balancer cannot exist on it's own as an entity in a SIP network -- it would have to have cooperating servers that would legislate against retransmissions being distributed arbitrarily. > UAS responsds with 200 to #1 and 4xx to #2 > which both are sent upstream to UAC. The question is: does 4xx terminate > the transaction according to 13.2.2.3. This situation cannot happen if the network is healthy. > > Retransmissions should always go to the same > > server (proxy). > > In a perfect world, yes. What if the proxy that forwards initial INVITE > goes down? Let's say its backup (through DNS lookup) has a slightly > different view of the network topology and sends retransmissions through > a different path. I could imagine clever proxies and UAs being able to recover this situation. If not, the caller will probably just retry. If I pick up the 'phone and attempt to make a call, and hear some strange tone on the line that I don't recognise, it's almost instinctive to just "give it another go". - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 08:41:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17829 for ; Wed, 31 Oct 2001 08:41:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16867 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 08:41:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16373; Wed, 31 Oct 2001 08:27:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16342 for ; Wed, 31 Oct 2001 08:27:24 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16998 for ; Wed, 31 Oct 2001 08:27:24 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 31 Oct 2001 13:27:27 UT Received: from jhornsby ([193.195.52.40]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 31 Oct 2001 13:29:22 +0000 From: "Jo Hornsby" To: "Christer Holmberg" , Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Wed, 31 Oct 2001 13:27:23 -0000 Message-ID: <000801c1620f$c6409fc0$2834c3c1@eu.ubiquity.net> 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 In-Reply-To: <3BDFD812.F34F2112@lmf.ericsson.se> X-OriginalArrivalTime: 31 Oct 2001 13:29:22.0029 (UTC) FILETIME=[0D0191D0:01C16210] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > >>>It would, though, be good if the branch value in the ACK to the 200 > >>>could be the same as the branch in the INVITE, so that they could be > >>>directly matched. > >>The entity that generates the branch for the ACK does not have to be > >>and typically is not) the same entity that generated the branch for the > >>INVITE. That's why ACKs for 2xx responses are slightly different than > >>ACKs for non-2xx final responses. > >I know. So, one could argue that the branch parameter shouldn't even be > >in the Via header - or another header/header value would be used for > >this. It could be somewhere else, so that the UAC could pick it from the > >200 response and use it in the ACK. > > I wonder if we could define some kind of "branch-tag" for this (as a To > header parameter, for example), which the UAS could insert in the final > responses to the INVITEs - or at least in the 200 response. The UAC > could then copy it to the ACK request, and it would then be used by the > UAS to match the ACK to the INVITE which generated the 200. > > Of course, the use of the tag would be optional, and if either party > doesn't support it the old mechanism would simply be used, ie assuming > that an ACK belongs to the INVITE which generated the 200 because the > Via branch value in the ACK doesn't match any value in the UAS. > > Comments? Yes: I fail to see the point. Since we have a well-defined, working, mechanism for detecting the ACK for the 200, why invent another way, which will not work in some cases? - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 09:08:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18913 for ; Wed, 31 Oct 2001 09:08:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18188 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 09:08:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16933; Wed, 31 Oct 2001 08:43:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16901 for ; Wed, 31 Oct 2001 08:43:33 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17898 for ; Wed, 31 Oct 2001 08:43:33 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 31 Oct 2001 13:43:40 UT Received: from jhornsby ([193.195.52.40]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 31 Oct 2001 13:45:34 +0000 From: "Jo Hornsby" To: "Christer Holmberg" Cc: Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Wed, 31 Oct 2001 13:43:35 -0000 Message-ID: <000a01c16212$09e1c950$2834c3c1@eu.ubiquity.net> 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 In-Reply-To: <3BDFFD38.35706FD2@lmf.ericsson.se> X-OriginalArrivalTime: 31 Oct 2001 13:45:34.0529 (UTC) FILETIME=[50A94B10:01C16212] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > > I wonder if we could define some kind of "branch-tag" for > > > this (as a To header parameter, for example), which the UAS > > > could insert in the final responses to the INVITEs - or at > > > least in the 200 response. The UAC could then copy it to the > > > ACK request, and it would then be used by the UAS to match > > > the ACK to the INVITE which generated the 200. > > > > > > Of course, the use of the tag would be optional, and if either party > > > doesn't support it the old mechanism would simply be used, ie assuming > > > that an ACK belongs to the INVITE which generated the 200 because the > > > Via branch value in the ACK doesn't match any value in the UAS. > > > > > > Comments? > > > >Yes: I fail to see the point. Since we have a well-defined, > >working, mechanism for detecting the ACK for the 200, why > >invent another way, which will not work in some cases? > > I want to point out that I am NOT talking about a normal 200/ACK > matching, but the case where a forked INVITE gets merged in the UAS and > the UAS sends multiple final responses (one 200 and multiple 482, for > example). The Via branch value will be identical in the INVITEs and ACKs > for the "482 legs", but not for the INVITE and ACK for the "200 leg". I realize that; my assertion remains: we have a working mechanism -- why augment it with an additional, and unreliable, extension? - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 09:30:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19759 for ; Wed, 31 Oct 2001 09:30:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18898 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 09:30:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16735; Wed, 31 Oct 2001 08:31:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16707 for ; Wed, 31 Oct 2001 08:31:48 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17121 for ; Wed, 31 Oct 2001 08:31:48 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VDVoC28084; Wed, 31 Oct 2001 14:31:50 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.74]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VDVnB19429; Wed, 31 Oct 2001 15:31:49 +0200 (EET) Message-ID: <3BDFFD38.35706FD2@lmf.ericsson.se> Date: Wed, 31 Oct 2001 15:31:36 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <000801c1620f$c6409fc0$2834c3c1@eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Jo Hornsby wrote: > > > >>>It would, though, be good if the branch value in the ACK to the 200 > > >>>could be the same as the branch in the INVITE, so that they could be > > >>>directly matched. > > >>The entity that generates the branch for the ACK does not have to be > > >>and typically is not) the same entity that generated the branch for the > > >>INVITE. That's why ACKs for 2xx responses are slightly different than > > >>ACKs for non-2xx final responses. > > >I know. So, one could argue that the branch parameter shouldn't even be > > >in the Via header - or another header/header value would be used for > > >this. It could be somewhere else, so that the UAC could pick it from the > > >200 response and use it in the ACK. > > > > I wonder if we could define some kind of "branch-tag" for this (as a To > > header parameter, for example), which the UAS could insert in the final > > responses to the INVITEs - or at least in the 200 response. The UAC > > could then copy it to the ACK request, and it would then be used by the > > UAS to match the ACK to the INVITE which generated the 200. > > > > Of course, the use of the tag would be optional, and if either party > > doesn't support it the old mechanism would simply be used, ie assuming > > that an ACK belongs to the INVITE which generated the 200 because the > > Via branch value in the ACK doesn't match any value in the UAS. > > > > Comments? > >Yes: I fail to see the point. Since we have a well-defined, >working, mechanism for detecting the ACK for the 200, why >invent another way, which will not work in some cases? I want to point out that I am NOT talking about a normal 200/ACK matching, but the case where a forked INVITE gets merged in the UAS and the UAS sends multiple final responses (one 200 and multiple 482, for example). The Via branch value will be identical in the INVITEs and ACKs for the "482 legs", but not for the INVITE and ACK for the "200 leg". Regards, Christer Holmberg Ericsson Finland > > - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 09:52:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20619 for ; Wed, 31 Oct 2001 09:52:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA19570 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 09:52:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18784; Wed, 31 Oct 2001 09:26:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18753 for ; Wed, 31 Oct 2001 09:26:50 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19622 for ; Wed, 31 Oct 2001 09:26:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9VEOSb7016633; Wed, 31 Oct 2001 09:24:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 09:25:43 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E736@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Christer Holmberg'" , Shan Lu Cc: "'Gonzalo Camarillo'" , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 09:25:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org inline > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, October 30, 2001 11:40 PM > To: Shan Lu > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg' > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > Hi, > > I understand the arguments for buffering. BUT, by waiting for > the first > 1xx we still don't solve the CANCEL/200 race condition. Yes, we've solved this one. More after the answer to the scenario below. > > Also, consider the following case: > > > |------- UAS 1 > UAC --- P1 > |------- UAS 2 > > > Now, the UAC sends an INVITE, which gets forked by P1. P1 > also sends 100 > back to UAC. Then, the UAC decides to terminate the setup, so it sends > CANCEL. > > Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL > there. > > HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do > that. Instead, the UAS 2 returns 200 OK immedeately. So, what > does P1 do > now? Creates a BYE transaction to UAS 2 - and when it receives a > response to that it sends 200 for the CANCEL to the UAC??? > This sounds a > little like B2BUA behaviour to me... Its more than a little like B2BUA - P1 cannot generate a BYE on its own. Once you take that step, you are no longer talking about proxies. > > > AND, the following (easier case) could also have happened in the > scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when > P1 sends a > CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? > > 1. Create a BYE to both UAS 1 and UAS 2? > > 2. Forward the 200 response for the INVITE to the UAC, and > sends 487 for > the CANCEL to the UAC? Neither. The scenario you set up will play out as follows: UAC P1 UAS1 UAS2 |INVITE | | | |------------->| INVITE | | | 100 |------------->| | |<-------------| | INVITE | | |----------------------------->| | | 100 | | | CANCEL |<-------------| | |------------->| | | | 200 (CANCEL) | | | |<-------------| CANCEL | | | |------------->| | | | 200 (CANCEL) | | | |<-------------| | | | 487 (INVITE) | | | |<-------------| | | | ACK | | | |------------->| | | | | 200 (INVITE) | | 200 (INVITE) |<-----------------------------| |<-------------| | | | ACK | | | |------------->| ACK | | | |----------------------------->| | | | | | | | | | | | | CANCEL is hop-hop. All that a 200 means to a CANCEL is that it got to the next hop, not that something actually got cancelled. A CANCEL will never recieve a 487 response (as you suggest in step 2 above. Those only come in responses to requests that got cancelled. Now, for the CANCEL 200 race condition - that's effectively what you set up with UAS2 above (leave UAS1 out of the diagram). At the end of the scenario, UAC knows that 1) The next hop got its CANCEL request, and 2) It didn't get to the far side in time to CANCEL the request (since it got a 200 to the INVITE). Everyone is in sync - no crossing problem. > > > >>As I stated previously, if the CANCEL arrives to the server > before the > >>INVITE, the UAC will not have any way to cancel the request. Then it > >>would have to wait until the INVITE is answered in order to send a > >>BYE... and this can really take very long. > >Why can't BYE be sent for an early dialog to terminate the dialog? > > This has been discussed before, and the UAC CAN use BYE to terminate a > dialog, assuming it has received a 1xx with a To header tag. > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 10:11:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21190 for ; Wed, 31 Oct 2001 10:11:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20503 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 10:11:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19520; Wed, 31 Oct 2001 09:48:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19493 for ; Wed, 31 Oct 2001 09:48:15 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20499 for ; Wed, 31 Oct 2001 09:48:14 -0500 (EST) Received: (qmail 28090 invoked from network); 31 Oct 2001 14:41:00 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 31 Oct 2001 14:41:00 -0000 From: "Shan Lu" To: "'Gonzalo Camarillo'" Cc: "IETF SIP Mailing List" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 09:47:38 -0500 Message-ID: <000201c1621a$fc84adf0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BDF4701.DB3A4140@lmf.ericsson.se> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, October 30, 2001 7:34 PM > To: Shan Lu > Subject: Re: [Sip] Bis-05 question: CANCEL > > > Hello, > > Shan Lu wrote: > > > Why can't BYE be sent for an early dialog to terminate the dialog? > > Because nobody ensures you that the UAS will send you provisional > responses. Therefore, if no early dialog is created, the UAC > would have > to store state "for ever", if the 200 OK for the INVITE takes > very long. > > Remember that it is possible to establish a dialog without a previous > early dialog. > Agreed. Then I don't understand how waiting-for-1xx-then-CANCEL rule helps you in this scenario. You will never receive 1xx and therefore you never CANCEL and UAC will have to store state forever or till final response arrives. Regards, Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 10:25:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21595 for ; Wed, 31 Oct 2001 10:25:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21097 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 10:25:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20255; Wed, 31 Oct 2001 10:06:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20224 for ; Wed, 31 Oct 2001 10:06:49 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21058 for ; Wed, 31 Oct 2001 10:06:48 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9VF65Y14135; Wed, 31 Oct 2001 09:06:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VF64e22965; Wed, 31 Oct 2001 09:06:04 -0600 (CST) Received: from lmf.ericsson.se (rmt160152.am.ericsson.se [138.85.160.152]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA15863; Wed, 31 Oct 2001 09:06:02 -0600 (CST) Message-ID: <3BE01850.C8EEF383@lmf.ericsson.se> Date: Wed, 31 Oct 2001 17:27:12 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shan Lu CC: IETF SIP Mailing List Subject: Re: [Sip] Bis-05 question: CANCEL References: <000201c1621a$fc84adf0$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, inline: Shan Lu wrote: > > Hi, > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, October 30, 2001 7:34 PM > > To: Shan Lu > > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > > > Hello, > > > > Shan Lu wrote: > > > > > Why can't BYE be sent for an early dialog to terminate the dialog? > > > > Because nobody ensures you that the UAS will send you provisional > > responses. Therefore, if no early dialog is created, the UAC > > would have > > to store state "for ever", if the 200 OK for the INVITE takes > > very long. > > > > Remember that it is possible to establish a dialog without a previous > > early dialog. > > > > Agreed. Then I don't understand how waiting-for-1xx-then-CANCEL rule > helps you in this scenario. You will never receive 1xx and therefore you > never CANCEL and UAC will have to store state forever or till final > response arrives. > Remember that 100 Trying responses are different than other 2xx responses. You can perfectly not receive a 1xx response because the UAS decides not to send them. Or because it simply gets lost. However, the 100 response will always be sent by the next hop (unless the final response takes less than 200 ms, which is unlikely). You will be retransmitting your INVITE until you receive the 100 Trying. If it never arrives, you consider the transaction terminated, as decribed in bis-05. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 10:28:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21650 for ; Wed, 31 Oct 2001 10:28:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21218 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 10:28:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20562; Wed, 31 Oct 2001 10:11:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20531 for ; Wed, 31 Oct 2001 10:11:40 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21224 for ; Wed, 31 Oct 2001 10:11:40 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9VFBC024993; Wed, 31 Oct 2001 09:11:12 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VFBCe26492; Wed, 31 Oct 2001 09:11:12 -0600 (CST) Received: from lmf.ericsson.se (rmt160152.am.ericsson.se [138.85.160.152]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA16602; Wed, 31 Oct 2001 09:11:08 -0600 (CST) Message-ID: <3BE01981.4B55F5CE@lmf.ericsson.se> Date: Wed, 31 Oct 2001 17:32:17 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Bob Penfield , sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: <3BDE40D9.D77E29E3@lmf.ericsson.se> <017c01c1614b$c01c34c0$2300000a@acmepacket.com> <3BDEB6C4.DF72048B@lmf.ericsson.se> <3BDED540.1FD97B7F@lmf.ericsson.se> <3BDF8F58.B231B4E1@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Christer Holmberg wrote: > > Hi, > > >>Yes. I was just worried about cases where it actually may take a > >>relatively long time before the 200 final response is sent, due to other > >>call setup actions (PRACK, INFO etc), because I guess the proxy won't > >>wait "forever" for the final response until it takes some actions (of > >>course, in a real-life situation the call setup probably won't be that > >>long) for the pending legs. > >> > > > >The proxy has ACKed already the 482 response. The only thing it does is > >to store it in a buffer as one of the non-2xx final responses received > >so far. This way it will be able to choose the "best" one to send back. > > > >I do not know why you are raising this now, because this has been > >standard SIP behavior since the beginning. > > I just wanted to clarify the specific case where it takes a long time > before the final response is received for a specific leg, because the > use of call pre-setup transactions etc has NOT been standard SIP > behavious since the beginning... > You are confusing terms. What you are saying does not have anything to do with what we are discussing. It does not matter if you send thousands of messages (PRACKs, COMETs, you name it...) before the call is set up, because even if you do not send any message (a simple INVITE-final response-ACK), the final response MAY take a long time to arrive... it could eventually take even longer than in the other scenario if the user chooses not to pick up inmediately... Therefore, we are discussing an scenario that has been there since the beginning of SIP. No new discussions really needed. Let's close this thread. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 10:29:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21668 for ; Wed, 31 Oct 2001 10:28:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21234 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 10:28:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20377; Wed, 31 Oct 2001 10:07:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20267 for ; Wed, 31 Oct 2001 10:07:17 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21082 for ; Wed, 31 Oct 2001 10:07:17 -0500 (EST) Received: (qmail 29594 invoked from network); 31 Oct 2001 15:00:03 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 31 Oct 2001 15:00:03 -0000 From: "Shan Lu" To: "'Jo Hornsby'" , Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Date: Wed, 31 Oct 2001 10:06:41 -0500 Message-ID: <000301c1621d$a5c6fe20$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <000701c1620e$99311740$2834c3c1@eu.ubiquity.net> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I think the discussion on "load balancer" has been side tracked. My original point (and I think you actually agreed) is that retransmissions of the same INVITE can arrive at the same UAS through different paths. According to the rules in section 13.3.1, line 1816, this would cause the call to be terminated. That's all I wanted to point out. What is the solution or whether it warrants a solution, I don't know. Regards, Shan Lu sentitO Networks > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Jo Hornsby > Sent: Wednesday, October 31, 2001 8:19 AM > To: Shan Lu; sip@ietf.org > Subject: RE: [Sip] Handling of duplicate requests with > differing request paths. > > > > > This load balancer is broken, then; or, at least, > > > the system that it is working in as a whole is > > > broken. It should not be possible to observe > > > any such behaviour from any other SIP client's / > > > server's perspective. > > > > > > > Not sure what is broken. Load balancer forwards INVITE #1 > to Proxy #1 > > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing > wrong for a > > stateless load balancer. > > Uh. Maybe there is nothing wrong with the "stateless > load balancer" (I don't know what its mandate is), > but it certainly represents no entity that I am aware > of in the spec, and thus will break the network if > the "proxy"s behind it are not aware that there is a > "stateless load balancer" serving them. > > What I'm saying is that this load balancer cannot > exist on it's own as an entity in a SIP network -- > it would have to have cooperating servers that would > legislate against retransmissions being distributed > arbitrarily. > > > UAS responsds with 200 to #1 and 4xx to #2 > > which both are sent upstream to UAC. The question is: does > 4xx terminate > > the transaction according to 13.2.2.3. > > This situation cannot happen if the network is > healthy. > > > > Retransmissions should always go to the same > > > server (proxy). > > > > In a perfect world, yes. What if the proxy that forwards > initial INVITE > > goes down? Let's say its backup (through DNS lookup) has a slightly > > different view of the network topology and sends > retransmissions through > > a different path. > > I could imagine clever proxies and UAs being > able to recover this situation. If not, the > caller will probably just retry. If I pick up > the 'phone and attempt to make a call, and hear > some strange tone on the line that I don't > recognise, it's almost instinctive to just > "give it another go". > > > - Jo. > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 10:30:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21697 for ; Wed, 31 Oct 2001 10:30:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21260 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 10:30:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20438; Wed, 31 Oct 2001 10:10:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20413 for ; Wed, 31 Oct 2001 10:10:02 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21153 for ; Wed, 31 Oct 2001 10:10:01 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A44CD7ED00AC; Wed, 31 Oct 2001 10:10:04 -0500 Message-ID: <00eb01c1621d$1558cf80$2300000a@acmepacket.com> From: "Bob Penfield" To: "Shan Lu" Cc: "IETF SIP Mailing List" References: <000201c1621a$fc84adf0$eb00000a@SAJAK> Subject: Re: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 10:02:39 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Shan Lu" To: "'Gonzalo Camarillo'" Cc: "IETF SIP Mailing List" Sent: Wednesday, October 31, 2001 9:47 AM Subject: RE: [Sip] Bis-05 question: CANCEL > Hi, > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, October 30, 2001 7:34 PM > > To: Shan Lu > > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > > > Hello, > > > > Shan Lu wrote: > > > > > Why can't BYE be sent for an early dialog to terminate the dialog? > > > > Because nobody ensures you that the UAS will send you provisional > > responses. Therefore, if no early dialog is created, the UAC > > would have > > to store state "for ever", if the 200 OK for the INVITE takes > > very long. > > > > Remember that it is possible to establish a dialog without a previous > > early dialog. > > > > Agreed. Then I don't understand how waiting-for-1xx-then-CANCEL rule > helps you in this scenario. You will never receive 1xx and therefore you > never CANCEL and UAC will have to store state forever or till final > response arrives. > Most of the time, you will receive a 1xx. Even if you did send the CANCEL right away, you still have to wait for the final response to the INVITE before you can forget about it (delete the transaction state). You still have to be prepared to ACK and BYE if you get a 200 response to the INVITE. You still have transaction state, so it is easy to send the CANCEL as soon as you get a 1xx. I think the problems of the CANCEL beating the INVITE far outway any benefits of sending the CANCEL right away. > Regards, > > Shan Lu > sentitO Networks > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 10:33:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21877 for ; Wed, 31 Oct 2001 10:33:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21912 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 10:33:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20707; Wed, 31 Oct 2001 10:15:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20678 for ; Wed, 31 Oct 2001 10:15:54 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21349 for ; Wed, 31 Oct 2001 10:15:53 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9VFFQ027423; Wed, 31 Oct 2001 09:15:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VFFQO13862; Wed, 31 Oct 2001 09:15:26 -0600 (CST) Received: from lmf.ericsson.se (rmt160152.am.ericsson.se [138.85.160.152]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA17208; Wed, 31 Oct 2001 09:15:21 -0600 (CST) Message-ID: <3BE01A7F.BABE458F@lmf.ericsson.se> Date: Wed, 31 Oct 2001 17:36:31 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Bob Penfield , sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: <3BDE40D9.D77E29E3@lmf.ericsson.se> <017c01c1614b$c01c34c0$2300000a@acmepacket.com> <3BDEB6C4.DF72048B@lmf.ericsson.se> <3BDED540.1FD97B7F@lmf.ericsson.se> <3BDF8F58.B231B4E1@lmf.ericsson.se> <3BDF9985.5B66B21E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Christer Holmberg wrote: > > Hi, > > Just one more clarification related to this: > > The proxy forks an INVITE. Then it receives 482 for one leg, and waits > for the final responses also from the other legs. > > My question is: even if the proxy waits for the final responses, it > still DOES forward PROVISIONAL responses to the UAC, right? > What makes you think that the proxy stops forwarding provisional responses?... why would a proxy stop forwarding them? The answer is: "yes, it does forward them". But as I said already three times in this thread, this is not new SIP behavior at all. Questions related to this are probably best discussed in the SIP implementors list. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 10:43:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22113 for ; Wed, 31 Oct 2001 10:43:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22149 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 10:43:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21170; Wed, 31 Oct 2001 10:26:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21117 for ; Wed, 31 Oct 2001 10:26:39 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21615 for ; Wed, 31 Oct 2001 10:26:37 -0500 (EST) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9VFQ9a12290; Wed, 31 Oct 2001 07:26:09 -0800 (PST) Received: from arunvenkw2k (dhcp-64-101-150-140.cisco.com [64.101.150.140]) by sponge.cisco.com (Mirapoint) with SMTP id AAV10979; Wed, 31 Oct 2001 09:23:31 -0600 (CST) From: "A Venkatraman" To: , Date: Wed, 31 Oct 2001 09:30:21 -0600 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <61D824C63B99D311975E00508B0CC98502C66BEE@eamrcnt717.exu.ericsson.se> Content-Transfer-Encoding: 7bit Subject: [Sip] Use 599 instead of 482 fro Request Merged? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It has been stipulated in the spec that when two merged requests arrive at a UAS, the first one is processed and the second one is responded with a 482. Now, if the first request that is processed elicits a response higher than 482 (eg. 486 Busy) then the forking proxy will return the best response of 482 to the UAC. I support the suggestion of choosing a high response code, like 599. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of adam.roach@ericsson.com Sent: Monday, October 29, 2001 4:23 PM To: 'Shan Lu'; 'Jo Hornsby'; sip@ietf.org Subject: RE: [Sip] Handling of duplicate requests with differing request paths. Two issues: I was pretty sure that we had decided not to return an error code at all (since the forked messages may have gone through proxies that added proxy-require headers, etc); this would leave the clients to sort things out. That notwithstanding, if we are choosing a status code for this situation, we should make sure it doesn't override any other "useful" status codes at the proxy (by being a lower number). For example, a UA receiving a "482 Request Merged" is not ever useful. A 500 response, however, might convey some information. To avoid having a "Request Merged" response overriding a useful response, I'd suggest that we select status code 599 for request merging. Unless, of course, my first assertion was correct (and I do believe that it is): proxies shouldn't merge requests at all, and this should be a UAS issue. /a > -----Original Message----- > From: Shan Lu [mailto:shanlu@sentito.com] > Sent: Monday, October 29, 2001 4:11 PM > To: 'Jo Hornsby'; sip@ietf.org > Subject: RE: [Sip] Handling of duplicate requests with > differing request > paths. > > > > > > -----Original Message----- > > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > > Sent: Monday, October 29, 2001 12:21 PM > > To: Shan Lu; sip@ietf.org > > Subject: RE: [Sip] Handling of duplicate requests with > > differing request paths. > > > > > > > > Assume that the UAS receives the INVITE from two separate > > "routes". It > > > > sends 200 to the first one, and 482 to the other. > > > > > > > > > > Q1. Is 482 the proper response? This isn't a loop, is it? > > > > It's important not to get too hung-up on the > > default Reason Phrases. An implementor is > > free to use "Request Merged", or sommat, as > > the Reason Phrase that accompanies the 482. > > 482 is specified by bis-05, and I think > > fits very well semantically with the > > "classical" notion of a 482. > > This sounds like a pretty good reason to define a new cause > code rather > than let everybody come up with their own reason phase. > > > > > > Q2. 200 followd by 4xx works if the paths are due to a > > forking proxy, > > > which will sit there collecting responses and send upstream > > the "best > > > one". Now what if the requests travel different paths because a > > > stateless load balancer distributes requests round robin to > > a farm of > > > proxies and multiple requests end up in the same UAS? In > > this case, both > > > 200 and 4xx are received by the UAC. > > > > This load balancer is broken, then; or, at least, > > the system that it is working in as a whole is > > broken. It should not be possible to observe > > any such behaviour from any other SIP client's / > > server's perspective. > > > > Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1 > and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a > stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2 > which both are sent upstream to UAC. The question is: does > 4xx terminate > the transaction according to 13.2.2.3. > > > > Let's further assume that the UAS > > > responds with 1xx to the first request -- an early dialog > is setup. > > > According to 13.2.2.3, the subsequest 4xx causes the UAC to > > terminate > > > the INVITE transaction, which means the call is dropped. > > And what if the > > > 4xx arrives before 1xx? Does this mean that a load balancer > > here has to > > > be at least transaction stateful? This is also a valid case when > > > different proxies are used for retransmissions. > > > > Retransmissions should always go to the same > > server (proxy). > > In a perfect world, yes. What if the proxy that forwards > initial INVITE > goes down? Let's say its backup (through DNS lookup) has a slightly > different view of the network topology and sends > retransmissions through > a different path. > > > > Shan Lu > sentitO Networks > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 10:52:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22366 for ; Wed, 31 Oct 2001 10:52:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22330 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 10:52:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21401; Wed, 31 Oct 2001 10:30:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21349 for ; Wed, 31 Oct 2001 10:30:17 -0500 (EST) Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21746 for ; Wed, 31 Oct 2001 10:30:16 -0500 (EST) Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1]) by mail.net2phone.com (8.11.5/8.11.5) with ESMTP id f9VFTgf03098; Wed, 31 Oct 2001 10:29:42 -0500 (EST) Received: by mailsvr with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 10:30:11 -0500 Message-ID: <6F46FABB90ABD411BD690002B3152FB9467139@lkwmail01> From: Romel Khan To: "'Robert Sparks'" , "'Christer Holmberg'" , Shan Lu Cc: "'Gonzalo Camarillo'" , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 10:26:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org So the following scenario can happen with SIP bis 05, right? A caller makes a call. An Invite is sent out. Caller hangs up right away before any provisional response comes back. So a CANCEL is not sent because provisional response was not received. Callee starts ringing although caller has already hung up (very very bizarre!). 180 is sent back but gets lost. Callee picks up although caller is gone and a 200 OK is sent back (another very bizarre situation). Is it documented in SIP bis05 that the UAC will know to send a BYE in this scenario after receiving 200 OK right away and how can it be made sure that the caller, who may be long gone, will not get billed? How will fast-connects be handled (UAS sends 200 OK after receiving Invite, and no prov. response sent)? -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Wednesday, October 31, 2001 9:26 AM To: 'Christer Holmberg'; Shan Lu Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg Subject: RE: [Sip] Bis-05 question: CANCEL inline > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, October 30, 2001 11:40 PM > To: Shan Lu > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg' > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > Hi, > > I understand the arguments for buffering. BUT, by waiting for > the first > 1xx we still don't solve the CANCEL/200 race condition. Yes, we've solved this one. More after the answer to the scenario below. > > Also, consider the following case: > > > |------- UAS 1 > UAC --- P1 > |------- UAS 2 > > > Now, the UAC sends an INVITE, which gets forked by P1. P1 > also sends 100 > back to UAC. Then, the UAC decides to terminate the setup, so it sends > CANCEL. > > Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL > there. > > HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do > that. Instead, the UAS 2 returns 200 OK immedeately. So, what > does P1 do > now? Creates a BYE transaction to UAS 2 - and when it receives a > response to that it sends 200 for the CANCEL to the UAC??? > This sounds a > little like B2BUA behaviour to me... Its more than a little like B2BUA - P1 cannot generate a BYE on its own. Once you take that step, you are no longer talking about proxies. > > > AND, the following (easier case) could also have happened in the > scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when > P1 sends a > CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? > > 1. Create a BYE to both UAS 1 and UAS 2? > > 2. Forward the 200 response for the INVITE to the UAC, and > sends 487 for > the CANCEL to the UAC? Neither. The scenario you set up will play out as follows: UAC P1 UAS1 UAS2 |INVITE | | | |------------->| INVITE | | | 100 |------------->| | |<-------------| | INVITE | | |----------------------------->| | | 100 | | | CANCEL |<-------------| | |------------->| | | | 200 (CANCEL) | | | |<-------------| CANCEL | | | |------------->| | | | 200 (CANCEL) | | | |<-------------| | | | 487 (INVITE) | | | |<-------------| | | | ACK | | | |------------->| | | | | 200 (INVITE) | | 200 (INVITE) |<-----------------------------| |<-------------| | | | ACK | | | |------------->| ACK | | | |----------------------------->| | | | | | | | | | | | | CANCEL is hop-hop. All that a 200 means to a CANCEL is that it got to the next hop, not that something actually got cancelled. A CANCEL will never recieve a 487 response (as you suggest in step 2 above. Those only come in responses to requests that got cancelled. Now, for the CANCEL 200 race condition - that's effectively what you set up with UAS2 above (leave UAS1 out of the diagram). At the end of the scenario, UAC knows that 1) The next hop got its CANCEL request, and 2) It didn't get to the far side in time to CANCEL the request (since it got a 200 to the INVITE). Everyone is in sync - no crossing problem. > > > >>As I stated previously, if the CANCEL arrives to the server > before the > >>INVITE, the UAC will not have any way to cancel the request. Then it > >>would have to wait until the INVITE is answered in order to send a > >>BYE... and this can really take very long. > >Why can't BYE be sent for an early dialog to terminate the dialog? > > This has been discussed before, and the UAC CAN use BYE to terminate a > dialog, assuming it has received a 1xx with a To header tag. > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 11:05:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22836 for ; Wed, 31 Oct 2001 11:05:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23107 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 11:05:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20156; Wed, 31 Oct 2001 10:04:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20129 for ; Wed, 31 Oct 2001 10:04:02 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20970 for ; Wed, 31 Oct 2001 10:04:02 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A2E4D0AE00AC; Wed, 31 Oct 2001 10:04:04 -0500 Message-ID: <00dd01c1621c$3fdc67e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" Cc: "'IETF SIP Mailing List'" References: <000001c16197$7cd62710$eb00000a@SAJAK> <3BDF8EBF.8830C80A@lmf.ericsson.se> Subject: Re: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 09:56:41 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christer Holmberg" To: "Shan Lu" Cc: "'Gonzalo Camarillo'" ; "'IETF SIP Mailing List'" ; "'Jonathan Rosenberg'" Sent: Wednesday, October 31, 2001 12:40 AM Subject: Re: [Sip] Bis-05 question: CANCEL > > Hi, > > I understand the arguments for buffering. BUT, by waiting for the first > 1xx we still don't solve the CANCEL/200 race condition. > The solution to the CANCEL/200 race condition has always been for the UAC to be prepared to ACK and BYE if it gets a 200 instead of a 487. There is no difference here. The UAC must always wait for the final response to the INVITE. > Also, consider the following case: > > > |------- UAS 1 > UAC --- P1 > |------- UAS 2 > > > Now, the UAC sends an INVITE, which gets forked by P1. P1 also sends 100 > back to UAC. Then, the UAC decides to terminate the setup, so it sends > CANCEL. > > Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL > there. > > HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do > that. Instead, the UAS 2 returns 200 OK immedeately. So, what does P1 do > now? Creates a BYE transaction to UAS 2 - and when it receives a > response to that it sends 200 for the CANCEL to the UAC??? This sounds a > little like B2BUA behaviour to me... Unless P1 is a B2BUA (i.e. maintaining dialog state and CSeq#s for requests), it cannot send the BYE. P1 must pass the 200-OK back to the UAC. Now, since the UAC has not received a final response to the INVITE, it must be prepared to send the ACK and BYE when it gets the 200-OK. This is still the classic "CANCEL and 200-OK passing on the wire". Their is no special behaviour required here. > > AND, the following (easier case) could also have happened in the > scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when P1 sends a > CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? > > 1. Create a BYE to both UAS 1 and UAS 2? > > 2. Forward the 200 response for the INVITE to the UAC, and sends 487 for > the CANCEL to the UAC? Both 200s must be forwarded to the UAC. 487 is not used as a response to a CANCEL. It is the response to an INVITE when an invite request has been cancelled. The CANCEL gets an immediate 200 response unless the request being cancelled is no longer present (then it gets a 481). > > > >>As I stated previously, if the CANCEL arrives to the server before the > >>INVITE, the UAC will not have any way to cancel the request. Then it > >>would have to wait until the INVITE is answered in order to send a > >>BYE... and this can really take very long. > >Why can't BYE be sent for an early dialog to terminate the dialog? > > This has been discussed before, and the UAC CAN use BYE to terminate a > dialog, assuming it has received a 1xx with a To header tag. Yes, that is true. But that's no reason to send a CANCEL before receiving a 1xx response. The main benefit of BYE for early dialog is terminating unwanted dialogs when a UAC gets 1xx/2xx responses from multiple UASs. > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 11:10:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22980 for ; Wed, 31 Oct 2001 11:10:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23310 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 11:10:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22262; Wed, 31 Oct 2001 10:47:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22233 for ; Wed, 31 Oct 2001 10:47:45 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22246 for ; Wed, 31 Oct 2001 10:46:35 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9VFkTY12119; Wed, 31 Oct 2001 09:46:29 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VFkTw07610; Wed, 31 Oct 2001 09:46:29 -0600 (CST) Received: from lmf.ericsson.se (rmt160152.am.ericsson.se [138.85.160.152]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA20308; Wed, 31 Oct 2001 09:46:26 -0600 (CST) Message-ID: <3BE021C8.38F2C8AC@lmf.ericsson.se> Date: Wed, 31 Oct 2001 18:07:36 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Romel Khan CC: "'Robert Sparks'" , "'Christer Holmberg'" , Shan Lu , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: Re: [Sip] Bis-05 question: CANCEL References: <6F46FABB90ABD411BD690002B3152FB9467139@lkwmail01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Romel Khan wrote: > > So the following scenario can happen with SIP bis 05, right? > > A caller makes a call. An Invite is sent out. Caller hangs up right away > before any provisional response comes back. So a CANCEL is not sent because > provisional response was not received. Callee starts ringing although caller > has already hung up (very very bizarre!). 180 is sent back but gets lost. In the meantime, the INVITE is being retransmitted until the 100 Trying arrives. In a typicaly scenario this will happen within one second. > Callee picks up although caller is gone and a 200 OK is sent back (another > very bizarre situation). > Is it documented in SIP bis05 that the UAC will know to send a BYE in this > scenario after receiving 200 OK right away and how can it be made sure that > the caller, who may be long gone, will not get billed? Billing does not have anything to do with bis-05, and yes, it is documented that CANCEL does not affect established dialog and that they should be shut down using BYE. > How will fast-connects be handled (UAS sends 200 OK after receiving Invite, > and no prov. response sent)? Established dialogs are terminated using BYE. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 11:41:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23862 for ; Wed, 31 Oct 2001 11:41:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25108 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 11:41:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23871; Wed, 31 Oct 2001 11:19:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23842 for ; Wed, 31 Oct 2001 11:19:51 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23287 for ; Wed, 31 Oct 2001 11:19:49 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 31 Oct 2001 16:19:57 UT Received: from jhornsby ([193.195.52.40]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 31 Oct 2001 16:21:52 +0000 From: "Jo Hornsby" To: "A Venkatraman" , , Subject: RE: [Sip] Use 599 instead of 482 fro Request Merged? Date: Wed, 31 Oct 2001 16:19:52 -0000 Message-ID: <001701c16227$de972ae0$2834c3c1@eu.ubiquity.net> 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 In-Reply-To: X-OriginalArrivalTime: 31 Oct 2001 16:21:52.0079 (UTC) FILETIME=[261DDDF0:01C16228] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > It has been stipulated in the spec that when two merged requests > arrive at a > UAS, the first one is processed and the second one is responded > with a 482. > > Now, if the first request that is processed elicits a response higher than > 482 (eg. 486 Busy) then the forking proxy will return the best response of > 482 to the UAC. > > I support the suggestion of choosing a high response code, like 599. 599 is in the wrong class. I would note that this is a general problem: for instance, 486 seems far more preferable to me than 404. Thus far, the notion of a "best" response has always been a little random; however, bis-05 seems to open things up nicely by allowing a proxy to "select" a response from the lowest class (step 5 of section 16.6). This then becomes a nonproblem. - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 11:59:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24265 for ; Wed, 31 Oct 2001 11:59:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25732 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 11:59:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25360; Wed, 31 Oct 2001 11:46:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25329 for ; Wed, 31 Oct 2001 11:46:00 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23984 for ; Wed, 31 Oct 2001 11:45:59 -0500 (EST) Received: (qmail 5170 invoked from network); 31 Oct 2001 16:38:45 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 31 Oct 2001 16:38:45 -0000 From: "Shan Lu" To: "'Gonzalo Camarillo'" , "'Romel Khan'" Cc: "'Robert Sparks'" , "'Christer Holmberg'" , "'IETF SIP Mailing List'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 11:45:23 -0500 Message-ID: <000a01c1622b$6fa6c240$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BE021C8.38F2C8AC@lmf.ericsson.se> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Wednesday, October 31, 2001 11:08 AM > To: Romel Khan > Cc: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'IETF SIP > Mailing List'; Jonathan Rosenberg > Subject: Re: [Sip] Bis-05 question: CANCEL > > > Hi, > > Romel Khan wrote: > > > > So the following scenario can happen with SIP bis 05, right? > > > > A caller makes a call. An Invite is sent out. Caller hangs > up right away > > before any provisional response comes back. So a CANCEL is > not sent because > > provisional response was not received. Callee starts > ringing although caller > > has already hung up (very very bizarre!). 180 is sent back > but gets lost. > > In the meantime, the INVITE is being retransmitted until the > 100 Trying > arrives. In a typicaly scenario this will happen within one second. > I am not sure where the one second comes from. Yes, the UAS is required to send 100 Trying under almost all situations in bis-05. But it does not guarantee that the 100 Trying will be received by UAC in any time frame. Yes, the UAC can and will continue to resend INVITE till any response is received. But in the meantime the phone may be ringing off the hook at the UAS side and the user may actually pick up before any 100 Trying arrives at UAC. This dead phone syndrome at the UAS side should be avoided at all costs. I understand that there is race condition that the protocol needs to resolve. In fact, there is a solution (BYE dialog if CANCEL beats out INVITE) that minimizes interefence on user experiences. Regards, Shan Lu sentitO Networks _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 12:04:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24540 for ; Wed, 31 Oct 2001 12:04:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26769 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 12:04:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25425; Wed, 31 Oct 2001 11:50:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25394 for ; Wed, 31 Oct 2001 11:50:22 -0500 (EST) Received: from gator.techcontrol.com ([63.122.248.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24064 for ; Wed, 31 Oct 2001 11:50:17 -0500 (EST) Received: by gator.techcontrol.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 11:47:10 -0500 Message-ID: <33890A53976FD41191A800B0D03DF1968F1D98@gator.techcontrol.com> From: "Shafique, Hashim" To: "'sip@ietf.org'" Date: Wed, 31 Oct 2001 11:47:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP-ISUP-03 draft SUS/RES INFO or RE-INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In Section 8.1 of the SIP-ISUP-03 draft, the call flows for SUS and RES show re-INVITEs. Should not the INFO method be used to carry mid call ISUP messages. Is there any reason why RE-INVITEs are used instead of INFO? Thanks HashimS. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 12:07:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24620 for ; Wed, 31 Oct 2001 12:07:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26989 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 12:07:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25674; Wed, 31 Oct 2001 11:55:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25641 for ; Wed, 31 Oct 2001 11:55:24 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24189 for ; Wed, 31 Oct 2001 11:55:22 -0500 (EST) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9VGt0X27719; Wed, 31 Oct 2001 08:55:01 -0800 (PST) Received: from arunvenkw2k (dhcp-64-101-150-140.cisco.com [64.101.150.140]) by sponge.cisco.com (Mirapoint) with SMTP id AAX00071; Wed, 31 Oct 2001 10:52:15 -0600 (CST) From: "A Venkatraman" To: "Christer Holmberg" , Subject: RE: [Sip] Another proxy-waiting-for-final-response case Date: Wed, 31 Oct 2001 10:59:04 -0600 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3BDFA537.25EAC9B7@lmf.ericsson.se> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer This case is no different from the following case - P1 forks to 2 UASes. P1 forwards 18x from 2 UASes back to the UAC. UAS1 sends 200, UAS2 sends 500 Internal Error P1 forwards only 200 response to UAC. UAC will never see the 500. How is UAC going to clean up the forked "leg" for which a final response was never received? This is implementation-specific to the UAC. For example, UAC may run a timer for the duration it will expect responses on forked legs. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, October 31, 2001 1:16 AM To: sip@ietf.org Subject: [Sip] Another proxy-waiting-for-final-response case Hi, Consider the following scenario: |------- UAS 1 | UAC --- P1------- UAS 2 | |------- UAS 3 Then: 1. UAC sends an INVITE, which gets forked to UAS 1, 2 and 3. 2. UAS 1 sends an 4xx response, which P1 "collects". 3. UAS 2 and UAS 3 both send 18x provisional responses (including To header tags), which are forwarded by P1 to the UAC. 4. The UAC wants to terminate the leg with UAS 3, so it sends BYE. 5. UAS 3 sends 200 for the BYE and 487 for the INVITE. Now, P1 forwards the 200 to the UAC, but it "collects" the 487. 6. UAS 2 sends 200 for the INVITE, and P1 now forwards that to the UAC, and the call is established. I guess this all works fine, but the point I want to make is that the UAC will never receive a 487 for the leg it terminated. Or? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 12:41:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25417 for ; Wed, 31 Oct 2001 12:41:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27804 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 12:41:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27226; Wed, 31 Oct 2001 12:18:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27195 for ; Wed, 31 Oct 2001 12:18:51 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24976 for ; Wed, 31 Oct 2001 12:18:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VHInf01336; Wed, 31 Oct 2001 18:18:49 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VHIlB26518; Wed, 31 Oct 2001 19:18:48 +0200 (EET) Message-ID: <3BE03284.18873E07@lmf.ericsson.se> Date: Wed, 31 Oct 2001 19:19:00 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Bob Penfield , sip@ietf.org Subject: Re: [Sip] 482 handling by proxies References: <3BDE40D9.D77E29E3@lmf.ericsson.se> <017c01c1614b$c01c34c0$2300000a@acmepacket.com> <3BDEB6C4.DF72048B@lmf.ericsson.se> <3BDED540.1FD97B7F@lmf.ericsson.se> <3BDF8F58.B231B4E1@lmf.ericsson.se> <3BDF9985.5B66B21E@lmf.ericsson.se> <3BE01A7F.BABE458F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Just one more clarification related to this: >> >>The proxy forks an INVITE. Then it receives 482 for one leg, and waits >>for the final responses also from the other legs. >> >>My question is: even if the proxy waits for the final responses, it >>still DOES forward PROVISIONAL responses to the UAC, right? >> > >What makes you think that the proxy stops forwarding provisional >responses?... why would a proxy stop forwarding them? > >The answer is: "yes, it does forward them". But as I said already three >times in this thread, this is not new SIP behavior at all. Questions >related to this are probably best discussed in the SIP implementors >list. I DID send a mail to the list, saying that I did find the text in the bis where this was said, and that the case was closed... Regards, Christer Holmberg Ericsson Finland > Regards, > > Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 13:03:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26198 for ; Wed, 31 Oct 2001 13:03:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29131 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 13:03:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27908; Wed, 31 Oct 2001 12:45:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27877 for ; Wed, 31 Oct 2001 12:45:44 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25500 for ; Wed, 31 Oct 2001 12:45:43 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VHjcf12705; Wed, 31 Oct 2001 18:45:38 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VHjbB27050; Wed, 31 Oct 2001 19:45:37 +0200 (EET) Message-ID: <3BE038C8.8C6EE4F4@lmf.ericsson.se> Date: Wed, 31 Oct 2001 19:45:44 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: Shan Lu , "'Gonzalo Camarillo'" , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: Re: [Sip] Bis-05 question: CANCEL References: <9BF66EBF6BEFD942915B4D4D45C051F338E736@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Now, the UAC sends an INVITE, which gets forked by P1. P1 >>also sends 100 back to UAC. Then, the UAC decides to terminate the setup, so it sends >>CANCEL. >> >>Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL >>there. >> >>HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do >>that. Instead, the UAS 2 returns 200 OK immedeately. So, what >>does P1 do now? Creates a BYE transaction to UAS 2 - and when it receives a >>response to that it sends 200 for the CANCEL to the UAC??? >>This sounds a little like B2BUA behaviour to me... > >Its more than a little like B2BUA - P1 cannot generate >a BYE on its own. Once you take that step, you are no >longer talking about proxies. Good! :) >>AND, the following (easier case) could also have happened in the >>scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when >>P1 sends a >>CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? >> >>1. Create a BYE to both UAS 1 and UAS 2? >> >>2. Forward the 200 response for the INVITE to the UAC, and >>sends 487 for the CANCEL to the UAC? > >Neither. > >The scenario you set up will play out as follows: > >UAC P1 UAS1 UAS2 > |INVITE | | | > |------------->| INVITE | | > | 100 |------------->| | > |<-------------| | INVITE | > | |----------------------------->| > | | 100 | | > | CANCEL |<-------------| | > |------------->| | | > | 200 (CANCEL) | | | > |<-------------| CANCEL | | > | |------------->| | > | | 200 (CANCEL) | | > | |<-------------| | > | | 487 (INVITE) | | > | |<-------------| | > | | ACK | | > | |------------->| | > | | | 200 (INVITE) | > | 200 (INVITE) |<-----------------------------| > |<-------------| | | > | ACK | | | > |------------->| ACK | | > | |----------------------------->| > | | | | > | | | | > | | | | > >CANCEL is hop-hop. All that a 200 means to a CANCEL >is that it got to the next hop, not that something >actually got cancelled. A CANCEL will never recieve >a 487 response (as you suggest in step 2 above. Those >only come in responses to requests that got cancelled. I am sorry. I meant that 481 (not 487) would be sent for the CANCEL. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 13:06:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26334 for ; Wed, 31 Oct 2001 13:06:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29220 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 13:06:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28284; Wed, 31 Oct 2001 12:52:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28255 for ; Wed, 31 Oct 2001 12:52:12 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25680 for ; Wed, 31 Oct 2001 12:52:10 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VHq7f15271; Wed, 31 Oct 2001 18:52:07 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VHq6B27224; Wed, 31 Oct 2001 19:52:06 +0200 (EET) Message-ID: <3BE03A53.79FB399A@lmf.ericsson.se> Date: Wed, 31 Oct 2001 19:52:19 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] Removal proposal: Password in SIP-URL References: <3BDF9028.C74493F1@lmf.ericsson.se> <3BDFF9CD.5436DE1A@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >If my recollection is correct, this suggestion has been discussed >before, at least once, and been rejected. Apparently, people do >implement it; the cost is essentially zero. (A header wouldn't add any >security benefit, but would make including the password, e.g., for a SIP >URL on a secure, private web page for friends, much more painful and >prone to errors.) Fair enough. However, if encryption is used, would be easier to encrypt a single header, because it could be encrypted together with the rest of the end-to-end headers (unless some proxy needs that password, of course). Then, if the password is not accpeted (it may have expired, it is not correct, or something similar...), what response code should the UAS send. 401? 403? Regards, Christer Holmberg Ericsson Finland > > Christer Holmberg wrote: > > > > Hi, > > > > The bis recommends that the password of the SIP-URL user part is not to > > be used. > > > > My question is: in this case, can't we remove it completely? OR, is > > there anyone who really uses it? > > > > In future, if someone wants to send passwords in SIP messages, a > > specific header (and maybe also even an option-tag) could be used for > > that. > > > > Comments? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 13:12:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26658 for ; Wed, 31 Oct 2001 13:12:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29727 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 13:12:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28408; Wed, 31 Oct 2001 12:57:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28377 for ; Wed, 31 Oct 2001 12:57:08 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25882 for ; Wed, 31 Oct 2001 12:57:07 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VHv8C14957; Wed, 31 Oct 2001 18:57:09 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VHv8B27303; Wed, 31 Oct 2001 19:57:08 +0200 (EET) Message-ID: <3BE03B81.DD60A1D2@lmf.ericsson.se> Date: Wed, 31 Oct 2001 19:57:21 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: sip@ietf.org Subject: Re: [Sip] Handling of duplicate requests with differing request paths. References: <000a01c16212$09e1c950$2834c3c1@eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>>Yes: I fail to see the point. Since we have a well-defined, >>>working, mechanism for detecting the ACK for the 200, why >>>invent another way, which will not work in some cases? >> >>I want to point out that I am NOT talking about a normal 200/ACK >>matching, but the case where a forked INVITE gets merged in the UAS and >>the UAS sends multiple final responses (one 200 and multiple 482, for >>example). The Via branch value will be identical in the INVITEs and ACKs >>for the "482 legs", but not for the INVITE and ACK for the "200 leg". > >I realize that; my assertion remains: we have >a working mechanism -- why augment it with an >additional, and unreliable, extension? I don't know if it's more reliable to assume that the ACK belongs to a specific INVITE just because you can't find a matching Via branch value... Anyway, I do think we have more important issues than this one, so we don't have to argue about it :) Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 13:33:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27337 for ; Wed, 31 Oct 2001 13:33:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01386 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 13:33:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00204; Wed, 31 Oct 2001 13:18:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00173 for ; Wed, 31 Oct 2001 13:18:29 -0500 (EST) Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26954 for ; Wed, 31 Oct 2001 13:18:29 -0500 (EST) Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1]) by mail.net2phone.com (8.11.5/8.11.5) with ESMTP id f9VIHxf29044; Wed, 31 Oct 2001 13:18:00 -0500 (EST) Received: by mailsvr with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 13:18:28 -0500 Message-ID: <6F46FABB90ABD411BD690002B3152FB946713E@lkwmail01> From: Romel Khan To: "'Gonzalo Camarillo'" Cc: "'Robert Sparks'" , "'Christer Holmberg'" , Shan Lu , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 13:15:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, It's logical and ok for billing to have nothing to do with bis-05, but service providers will be the ones to get stuck with any possible billing repercussions from these requirements. By the way, what is the probability that, using UDP, INVITE will be received after CANCEL? I assume a very small percentage of the time. Therefore, it would be preferrable that CANCEL be sent right away rather than consume resources by waiting for provisional responses for a moot reason. How about change "CANCEL must" wait for provisional response to "CANCEL should". Or how about a new procedure to handle the small number of cases that CANCEL may be received before INVITE: If 481 is received for a CANCEL, then the INVITE request that the CANCEL is trying to Cancel will be cancelled. And then apply a procedure related to call leg does not exist to the received provisional and final responses for the INVITE. (This probably is not consistent with current SIP philosophy of dealing with transactions & responses, but food for thought.) -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Wednesday, October 31, 2001 11:08 AM To: Romel Khan Cc: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'IETF SIP Mailing List'; Jonathan Rosenberg Subject: Re: [Sip] Bis-05 question: CANCEL Hi, Romel Khan wrote: > > So the following scenario can happen with SIP bis 05, right? > > A caller makes a call. An Invite is sent out. Caller hangs up right away > before any provisional response comes back. So a CANCEL is not sent because > provisional response was not received. Callee starts ringing although caller > has already hung up (very very bizarre!). 180 is sent back but gets lost. In the meantime, the INVITE is being retransmitted until the 100 Trying arrives. In a typicaly scenario this will happen within one second. > Callee picks up although caller is gone and a 200 OK is sent back (another > very bizarre situation). > Is it documented in SIP bis05 that the UAC will know to send a BYE in this > scenario after receiving 200 OK right away and how can it be made sure that > the caller, who may be long gone, will not get billed? Billing does not have anything to do with bis-05, and yes, it is documented that CANCEL does not affect established dialog and that they should be shut down using BYE. > How will fast-connects be handled (UAS sends 200 OK after receiving Invite, > and no prov. response sent)? Established dialogs are terminated using BYE. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 13:37:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27421 for ; Wed, 31 Oct 2001 13:37:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01484 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 13:37:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00502; Wed, 31 Oct 2001 13:25:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00471 for ; Wed, 31 Oct 2001 13:25:18 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27172 for ; Wed, 31 Oct 2001 13:25:17 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A20E3D5100AC; Wed, 31 Oct 2001 13:25:18 -0500 Message-ID: <019b01c16238$4902dea0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Shafique, Hashim" , References: <33890A53976FD41191A800B0D03DF1968F1D98@gator.techcontrol.com> Subject: Re: [Sip] SIP-ISUP-03 draft SUS/RES INFO or RE-INVITE Date: Wed, 31 Oct 2001 13:17:21 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit INVITEs must be used to convey SDP to cause the media flow to be stopped and restarted. INFO cannot be used because you're not allowed to change call state with INFO. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Shafique, Hashim" To: Sent: Wednesday, October 31, 2001 11:47 AM Subject: [Sip] SIP-ISUP-03 draft SUS/RES INFO or RE-INVITE > In Section 8.1 of the SIP-ISUP-03 draft, the call flows for SUS and RES show > re-INVITEs. Should not the INFO method be used to carry mid call ISUP > messages. Is there any reason why RE-INVITEs are used instead of INFO? > Thanks > HashimS. > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 13:42:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27564 for ; Wed, 31 Oct 2001 13:42:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01938 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 13:42:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00600; Wed, 31 Oct 2001 13:27:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00535 for ; Wed, 31 Oct 2001 13:27:00 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27198 for ; Wed, 31 Oct 2001 13:26:59 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9VIR0g07530 for ; Wed, 31 Oct 2001 13:27:00 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4SJRYB>; Wed, 31 Oct 2001 18:26:58 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC344B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Robert Sparks'" , "'Christer Holmberg'" , Shan Lu , "'Romel Khan'" Cc: "'Gonzalo Camarillo'" , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 18:26:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org None of this supposedly disastrous scenario for the SIP environment is any different to what happens in the PSTN/ISDN today. If you send a call request (SETUP/IAM or whatever) with full address into the PSTN/ISDN today, and then follow it up with a release, the first message will invariably reach the end terminal (and be processed there) before the second is received. There is therefore even today the chance that such a call is answered before the clear is received. This has been the case for years, and nobody has noticed. Will it really be a problem for SIP. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Romel Khan[SMTP:rkhan@net2phone.com] > Sent: 31 October 2001 15:26 > To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > Subject: RE: [Sip] Bis-05 question: CANCEL > > So the following scenario can happen with SIP bis 05, right? > > A caller makes a call. An Invite is sent out. Caller hangs up right away > before any provisional response comes back. So a CANCEL is not sent > because > provisional response was not received. Callee starts ringing although > caller > has already hung up (very very bizarre!). 180 is sent back but gets lost. > Callee picks up although caller is gone and a 200 OK is sent back (another > very bizarre situation). > Is it documented in SIP bis05 that the UAC will know to send a BYE in this > scenario after receiving 200 OK right away and how can it be made sure > that > the caller, who may be long gone, will not get billed? > How will fast-connects be handled (UAS sends 200 OK after receiving > Invite, > and no prov. response sent)? > > > > > > > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, October 31, 2001 9:26 AM > To: 'Christer Holmberg'; Shan Lu > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > Subject: RE: [Sip] Bis-05 question: CANCEL > > > inline > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, October 30, 2001 11:40 PM > > To: Shan Lu > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg' > > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > > > > > Hi, > > > > I understand the arguments for buffering. BUT, by waiting for > > the first > > 1xx we still don't solve the CANCEL/200 race condition. > > Yes, we've solved this one. More after the answer to the > scenario below. > > > > > Also, consider the following case: > > > > > > |------- UAS 1 > > UAC --- P1 > > |------- UAS 2 > > > > > > Now, the UAC sends an INVITE, which gets forked by P1. P1 > > also sends 100 > > back to UAC. Then, the UAC decides to terminate the setup, so it sends > > CANCEL. > > > > Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL > > there. > > > > HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do > > that. Instead, the UAS 2 returns 200 OK immedeately. So, what > > does P1 do > > now? Creates a BYE transaction to UAS 2 - and when it receives a > > response to that it sends 200 for the CANCEL to the UAC??? > > This sounds a > > little like B2BUA behaviour to me... > > Its more than a little like B2BUA - P1 cannot generate > a BYE on its own. Once you take that step, you are no > longer talking about proxies. > > > > > > > AND, the following (easier case) could also have happened in the > > scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when > > P1 sends a > > CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? > > > > 1. Create a BYE to both UAS 1 and UAS 2? > > > > 2. Forward the 200 response for the INVITE to the UAC, and > > sends 487 for > > the CANCEL to the UAC? > > Neither. > > The scenario you set up will play out as follows: > > UAC P1 UAS1 UAS2 > |INVITE | | | > |------------->| INVITE | | > | 100 |------------->| | > |<-------------| | INVITE | > | |----------------------------->| > | | 100 | | > | CANCEL |<-------------| | > |------------->| | | > | 200 (CANCEL) | | | > |<-------------| CANCEL | | > | |------------->| | > | | 200 (CANCEL) | | > | |<-------------| | > | | 487 (INVITE) | | > | |<-------------| | > | | ACK | | > | |------------->| | > | | | 200 (INVITE) | > | 200 (INVITE) |<-----------------------------| > |<-------------| | | > | ACK | | | > |------------->| ACK | | > | |----------------------------->| > | | | | > | | | | > | | | | > > CANCEL is hop-hop. All that a 200 means to a CANCEL > is that it got to the next hop, not that something > actually got cancelled. A CANCEL will never recieve > a 487 response (as you suggest in step 2 above. Those > only come in responses to requests that got cancelled. > > > Now, for the CANCEL 200 race condition - that's > effectively what you set up with UAS2 above > (leave UAS1 out of the diagram). At the end > of the scenario, UAC knows that > 1) The next hop got its CANCEL request, and > 2) It didn't get to the far side in time to > CANCEL the request (since it got a 200 to > the INVITE). > > Everyone is in sync - no crossing problem. > > > > > > > >>As I stated previously, if the CANCEL arrives to the server > > before the > > >>INVITE, the UAC will not have any way to cancel the request. Then it > > >>would have to wait until the INVITE is answered in order to send a > > >>BYE... and this can really take very long. > > >Why can't BYE be sent for an early dialog to terminate the dialog? > > > > This has been discussed before, and the UAC CAN use BYE to terminate a > > dialog, assuming it has received a 1xx with a To header tag. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 13:44:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27616 for ; Wed, 31 Oct 2001 13:44:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02004 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 13:44:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00925; Wed, 31 Oct 2001 13:29:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00894 for ; Wed, 31 Oct 2001 13:29:18 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27280 for ; Wed, 31 Oct 2001 13:29:18 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02581; Wed, 31 Oct 2001 13:28:43 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03075; Wed, 31 Oct 2001 13:28:44 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 Oct 2001 13:28:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0111A7B7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mpierce1@aol.com'" , sip@ietf.org Subject: RE: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-0 5 Date: Wed, 31 Oct 2001 13:28:42 -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@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have been, and am still very interested in being able to implement what is called MultiLevel Priority and Pre-emption in SIP. As you may recall, Jim Polk has made several proposals on this subject. The current priority levels are advisory, the values are not defined, and the current definition allows additional tokens to be used. I would like to propose that the next revision, bis-06 deprecate the current token values and substitute the 791 values. I believe that, as the old ones are indeed advisory, that any existing implementations would not break. If that is not acceptable, I'd propose that we ADD the RFC 791 tokens to the existing tokens, with language explaining what happened. Brian > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Friday, October 26, 2001 12:59 PM > To: jdrosen@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] Introducing the "new bis" - > draft-ietf-sip-rfc2543bis-05 > > > Jonathan, > > Regarding priority: > > In Section 26, BNF, (Page 185) the format for Priority got > mixed up. Some > extra spaces were inserted. > > We have to figure what these defined values mean for the > actual usage. The > question is: > > Why was the list of priorities taken from RFC 2076 rather > than from RFC 791? > RFC 2076 was informational and copied the list from RFC 1327 > (which was > obsoleted by RFC 2156), They addressed mapping between X.400 > and RFC 822, but > RFC 822 did not mention any such values. RFC 791 (and > appropriate existing > telephony standards) should form the basis of the priority > definition field > in SIP. > > At this point, since I presume that no one would agree to > deleting the > current values in RFC 2543, tokens should be added to > correspond to the 5 > values defined in RFC 791 (and also in current telephony > standards such as > ITU-T Q.735) which are required for military networks. > > The alternative, as I detailed in a previous e-mail, is to > add 5 new generic > values like "LEVEL0", "LEVEL1", "LEVEL 2", etc. and let > networks or countries > associate whatever words with these levels that they want. > > Also, there needs to be an explicit statement concerning the > order of the > present and the new values. There is no order specified for > the current set. > Different people would come to different conclusions about > the relative order > of "Routine" and "non-urgent". It needs to state that the > current four values > are in the descending order "emergency, urgent, routine, and > non-urgent". The > order of the 5 new values is as defined in RFC 791 and > applicable standards. > Also, there should be no defined relation between the current > set and the new > added set. It is not expected that they would be used > together, but if they > are, it is a local issue on how to handle them. > > Mike Pierce > Artel > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 13:57:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27833 for ; Wed, 31 Oct 2001 13:57:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02277 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 13:57:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01937; Wed, 31 Oct 2001 13:42:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01839 for ; Wed, 31 Oct 2001 13:42:46 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27557 for ; Wed, 31 Oct 2001 13:42:45 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9VIf8008527; Wed, 31 Oct 2001 12:41:08 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VIf8C19649; Wed, 31 Oct 2001 12:41:08 -0600 (CST) Received: from lmf.ericsson.se (rmt160223.am.ericsson.se [138.85.160.223]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA28282; Wed, 31 Oct 2001 12:41:05 -0600 (CST) Message-ID: <3BE04AB8.27625D3E@lmf.ericsson.se> Date: Wed, 31 Oct 2001 21:02:16 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Romel Khan CC: "'Robert Sparks'" , "'Christer Holmberg'" , Shan Lu , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: Re: [Sip] Bis-05 question: CANCEL References: <6F46FABB90ABD411BD690002B3152FB946713E@lkwmail01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Romel Khan wrote: > > Hi, > It's logical and ok for billing to have nothing to do with bis-05, but > service providers will be the ones to get stuck with any possible billing > repercussions from these requirements. > > By the way, what is the probability that, using UDP, INVITE will be received > after CANCEL? I assume a very small percentage of the time. Therefore, it > would be preferrable that CANCEL be sent right away rather than consume > resources by waiting for provisional responses for a moot reason. How about > change "CANCEL must" wait for provisional response to "CANCEL should". > Don't you undestand that what the harm that you can produce by being unable to hang up a call because the CANCEL made it before the INVITE is much higher than having to wait for a provisional response? About the chances of a CANCEL arriving before the INVITE, you only need one single message lost (the first transmission of the INVITE) and the caller hanging up in less than half a second... not a so strange scenario, I believe. > Or how about a new procedure to handle the small number of cases that CANCEL > may be received before INVITE: If 481 is received for a CANCEL, then the > INVITE request that the CANCEL is trying to Cancel will be cancelled. Jonathan and I have already explained several times in this thread that this causes DoS attacks. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 14:02:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27974 for ; Wed, 31 Oct 2001 14:02:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02943 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 14:02:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27774; Wed, 31 Oct 2001 12:38:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27748 for ; Wed, 31 Oct 2001 12:38:47 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25340 for ; Wed, 31 Oct 2001 12:38:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VHcmf10093; Wed, 31 Oct 2001 18:38:48 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VHclB26913; Wed, 31 Oct 2001 19:38:47 +0200 (EET) Message-ID: <3BE03734.5A9AF6F5@lmf.ericsson.se> Date: Wed, 31 Oct 2001 19:39:00 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: "'IETF SIP Mailing List'" Subject: Re: [Sip] Bis-05 question: CANCEL References: <000001c16197$7cd62710$eb00000a@SAJAK> <3BDF8EBF.8830C80A@lmf.ericsson.se> <00dd01c1621c$3fdc67e0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>I understand the arguments for buffering. BUT, by waiting for the first >>1xx we still don't solve the CANCEL/200 race condition. >> > >The solution to the CANCEL/200 race condition has always been for the UAC to >be prepared to ACK and BYE if it gets a 200 instead of a 487. There is no >difference here. The UAC must always wait for the final response to the >INVITE. I KNOW what the solution is. What I am saying is that since we DO have to THAT case into consideration in any case, we can use the SAME mechanism if we receive a 200 to an INVITE we have tried to CANCEL - ie we simply ACK and BYE it. My point is: does it really matter if the CANCEL reaches the UAS before the INVITE, OR if the CANCEL reaches the UAS after the 200 has been sent? In BOTH cases the UAC can use the same mechanism - ACK and BYE. >>Also, consider the following case: >> >> >> |------- UAS 1 >>UAC --- P1 >> |------- UAS 2 >> >> >>Now, the UAC sends an INVITE, which gets forked by P1. P1 also sends 100 >>back to UAC. Then, the UAC decides to terminate the setup, so it sends >>CANCEL. >> >>Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL >>there. >> >>HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do >>that. Instead, the UAS 2 returns 200 OK immedeately. So, what does P1 do >>now? Creates a BYE transaction to UAS 2 - and when it receives a >>response to that it sends 200 for the CANCEL to the UAC??? This sounds a >>little like B2BUA behaviour to me... > >Unless P1 is a B2BUA (i.e. maintaining dialog state and CSeq#s for >requests), it cannot send the BYE. P1 must pass the 200-OK back to the UAC. So, the UAC will receive 200 BOTH for the INVITE AND for the CANCEL, since the CANCEL did reach UAS 1? >Now, since the UAC has not received a final response to the INVITE, it must >be prepared to send the ACK and BYE when it gets the 200-OK. This is still >the classic "CANCEL and 200-OK passing on the wire". Their is no special >behaviour required here. I never said that (from a UAC point of view). Again, what I am saying that we could use the same ACK/BYE mechanism if a CANCEL reaches the UAS before the INVITE... >>AND, the following (easier case) could also have happened in the >>scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when P1 sends a >>CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? >> >>1. Create a BYE to both UAS 1 and UAS 2? >> >>2. Forward the 200 response for the INVITE to the UAC, and sends 487 for >>the CANCEL to the UAC? > >Both 200s must be forwarded to the UAC. 487 is not used as a response to a >CANCEL. Sorry, my misstake. I meant that 200 was sent for the CANCEL, and 487 for the INVITE. >It is the response to an INVITE when an invite request has been >cancelled. The CANCEL gets an immediate 200 response unless the request >being cancelled is no longer present (then it gets a 481). So, in this case we again receive 200 both for the INVITE and CANCEL, right? >>>>As I stated previously, if the CANCEL arrives to the server before the >>>>INVITE, the UAC will not have any way to cancel the request. Then it >>>>would have to wait until the INVITE is answered in order to send a >>>>BYE... and this can really take very long. >>>Why can't BYE be sent for an early dialog to terminate the dialog? >> >>This has been discussed before, and the UAC CAN use BYE to terminate a >>dialog, assuming it has received a 1xx with a To header tag. > >Yes, that is true. But that's no reason to send a CANCEL before receiving a >1xx response. Maybe not, but I still don't see a reason why I MUST wait for a 1xx before I send a CANCEL :) Again, I DO understand the idea behind waiting for 1xx, but I still think we already have mechanisms to handle situations that may occur even if we do NOT wait for the 1xx... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 14:13:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28303 for ; Wed, 31 Oct 2001 14:13:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03189 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 14:13:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02205; Wed, 31 Oct 2001 13:54:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02174 for ; Wed, 31 Oct 2001 13:54:05 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27755 for ; Wed, 31 Oct 2001 13:54:04 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9VIrZT13612 for ; Wed, 31 Oct 2001 13:53:36 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4SJSCC>; Wed, 31 Oct 2001 18:53:30 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC344C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Date: Wed, 31 Oct 2001 18:53:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Sip] Clarification of bis-05 changes requested Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org While I accept that the list of changes from the previous version does not have to be definitive, the current list of changes from -04 to -05 seems sparse in places. In particular I was trying to identify whether the Response-Key and Encryption headers had been intentionally removed - does that mean they no longer exist or are they about to pop up in another draft somewhere else? Also what is happening to the section that used to exist in -04 (Appendix B) on the use of SDP. Has it definitely been agreed that this becomes a draft elsewhere, and if so, where is it? Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 14:13:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28326 for ; Wed, 31 Oct 2001 14:13:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03206 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 14:13:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02249; Wed, 31 Oct 2001 13:55:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02220 for ; Wed, 31 Oct 2001 13:55:04 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27760 for ; Wed, 31 Oct 2001 13:55:03 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9VIsVY18032; Wed, 31 Oct 2001 13:54:31 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA18758; Wed, 31 Oct 2001 13:53:11 -0500 (EST) Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 13:54:31 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F91FA0D8@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: Bob Penfield , "Shafique, Hashim" , sip@ietf.org Subject: RE: [Sip] SIP-ISUP-03 draft SUS/RES INFO or RE-INVITE Date: Wed, 31 Oct 2001 13:53:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org (A note: In general, INFO can ONLY be used where no call states need to be changed (e.g., user-to-user information, states of some functional entities [e.g., impact on SIP layer services due to radio link outages]) - RRR -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Wednesday, October 31, 2001 1:17 PM To: Shafique, Hashim; sip@ietf.org Subject: Re: [Sip] SIP-ISUP-03 draft SUS/RES INFO or RE-INVITE INVITEs must be used to convey SDP to cause the media flow to be stopped and restarted. INFO cannot be used because you're not allowed to change call state with INFO. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Shafique, Hashim" To: Sent: Wednesday, October 31, 2001 11:47 AM Subject: [Sip] SIP-ISUP-03 draft SUS/RES INFO or RE-INVITE > In Section 8.1 of the SIP-ISUP-03 draft, the call flows for SUS and RES show > re-INVITEs. Should not the INFO method be used to carry mid call ISUP > messages. Is there any reason why RE-INVITEs are used instead of INFO? > Thanks > HashimS. > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 14:16:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28472 for ; Wed, 31 Oct 2001 14:16:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03246 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 14:16:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02323; Wed, 31 Oct 2001 13:58:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02292 for ; Wed, 31 Oct 2001 13:58:21 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27871 for ; Wed, 31 Oct 2001 13:58:20 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VIvpC23496; Wed, 31 Oct 2001 19:57:51 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VIvoB28520; Wed, 31 Oct 2001 20:57:50 +0200 (EET) Message-ID: <3BE049B5.8C7A6C07@lmf.ericsson.se> Date: Wed, 31 Oct 2001 20:57:57 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: "Shafique, Hashim" , sip@ietf.org Subject: Re: [Sip] SIP-ISUP-03 draft SUS/RES INFO or RE-INVITE References: <33890A53976FD41191A800B0D03DF1968F1D98@gator.techcontrol.com> <019b01c16238$4902dea0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, This has been much discussed before, and one problem is what network scenario you are looking at: Consider the following case: PSTN1 ---- GW1 ---- SIP ---- GW2 ---- PSTN2 Now, in this case you may not want your gateways (GW) to do anything to the media, but simply forward the SUS/RES messages from one PSTN side to the other. If you don't support ISUP MIME, the only way is for GW1 to generate a re-INVITE. BUT, you still don't want GW2 to do anything to the media, but simply to generate SUS/RES towards the other PSTN side. So, the question is: should a PSTN/SIP GW be allowed to map a call hold/un-hold message into a SUS/RES, without doing anything to the media? Regards, Christer Holmberg Ericsson Finland Bob Penfield wrote: > > INVITEs must be used to convey SDP to cause the media flow to be stopped and > restarted. INFO cannot be used because you're not allowed to change call > state with INFO. > > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Shafique, Hashim" > To: > Sent: Wednesday, October 31, 2001 11:47 AM > Subject: [Sip] SIP-ISUP-03 draft SUS/RES INFO or RE-INVITE > > > In Section 8.1 of the SIP-ISUP-03 draft, the call flows for SUS and RES > show > > re-INVITEs. Should not the INFO method be used to carry mid call ISUP > > messages. Is there any reason why RE-INVITEs are used instead of INFO? > > Thanks > > HashimS. > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 14:41:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28934 for ; Wed, 31 Oct 2001 14:41:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04388 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 14:41:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03573; Wed, 31 Oct 2001 14:28:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03542 for ; Wed, 31 Oct 2001 14:28:19 -0500 (EST) Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28699 for ; Wed, 31 Oct 2001 14:28:18 -0500 (EST) Received: (qmail 17172 invoked from network); 31 Oct 2001 19:21:03 -0000 Received: from unknown (HELO SAJAK) (10.0.0.235) by face.sentito.com with SMTP; 31 Oct 2001 19:21:03 -0000 From: "Shan Lu" To: "'Drage, Keith \(Keith\)'" Cc: "'IETF SIP Mailing List'" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 14:27:41 -0500 Message-ID: <001101c16242$1bf88540$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <475FF955A05DD411980D00508B6D5FB001AC344B@en0033exch001u.uk.lucent.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The only difference is that in PSTN you don't keep ringing the phone 30s after the caller has hung up, do you? Shan Lu sentitO Networks > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Drage, Keith (Keith) > Sent: Wednesday, October 31, 2001 1:27 PM > To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'Romel Khan' > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > Subject: RE: [Sip] Bis-05 question: CANCEL > > > None of this supposedly disastrous scenario for the SIP > environment is any > different to what happens in the PSTN/ISDN today. If you send > a call request > (SETUP/IAM or whatever) with full address into the PSTN/ISDN > today, and then > follow it up with a release, the first message will > invariably reach the end > terminal (and be processed there) before the second is > received. There is > therefore even today the chance that such a call is answered > before the > clear is received. > > This has been the case for years, and nobody has noticed. > > Will it really be a problem for SIP. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Romel Khan[SMTP:rkhan@net2phone.com] > > Sent: 31 October 2001 15:26 > > To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; > Jonathan Rosenberg > > Subject: RE: [Sip] Bis-05 question: CANCEL > > > > So the following scenario can happen with SIP bis 05, right? > > > > A caller makes a call. An Invite is sent out. Caller hangs > up right away > > before any provisional response comes back. So a CANCEL is not sent > > because > > provisional response was not received. Callee starts > ringing although > > caller > > has already hung up (very very bizarre!). 180 is sent back > but gets lost. > > Callee picks up although caller is gone and a 200 OK is > sent back (another > > very bizarre situation). > > Is it documented in SIP bis05 that the UAC will know to > send a BYE in this > > scenario after receiving 200 OK right away and how can it > be made sure > > that > > the caller, who may be long gone, will not get billed? > > How will fast-connects be handled (UAS sends 200 OK after receiving > > Invite, > > and no prov. response sent)? > > > > > > > > > > > > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Wednesday, October 31, 2001 9:26 AM > > To: 'Christer Holmberg'; Shan Lu > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > > Subject: RE: [Sip] Bis-05 question: CANCEL > > > > > > inline > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Tuesday, October 30, 2001 11:40 PM > > > To: Shan Lu > > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; > 'Jonathan Rosenberg' > > > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > > > > > > > > > Hi, > > > > > > I understand the arguments for buffering. BUT, by waiting for > > > the first > > > 1xx we still don't solve the CANCEL/200 race condition. > > > > Yes, we've solved this one. More after the answer to the > > scenario below. > > > > > > > > Also, consider the following case: > > > > > > > > > |------- UAS 1 > > > UAC --- P1 > > > |------- UAS 2 > > > > > > > > > Now, the UAC sends an INVITE, which gets forked by P1. P1 > > > also sends 100 > > > back to UAC. Then, the UAC decides to terminate the > setup, so it sends > > > CANCEL. > > > > > > Now, P1 has also received 1xx from UAS 1, so it can send > the CANCEL > > > there. > > > > > > HOWEVER, P1 has NOT received a 1xx from UAS 2, and it > won't even do > > > that. Instead, the UAS 2 returns 200 OK immedeately. So, what > > > does P1 do > > > now? Creates a BYE transaction to UAS 2 - and when it receives a > > > response to that it sends 200 for the CANCEL to the UAC??? > > > This sounds a > > > little like B2BUA behaviour to me... > > > > Its more than a little like B2BUA - P1 cannot generate > > a BYE on its own. Once you take that step, you are no > > longer talking about proxies. > > > > > > > > > > > AND, the following (easier case) could also have happened in the > > > scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when > > > P1 sends a > > > CANCEL both UAS 1 and UAS 2 have sent 200 - so what does > P1 do now? > > > > > > 1. Create a BYE to both UAS 1 and UAS 2? > > > > > > 2. Forward the 200 response for the INVITE to the UAC, and > > > sends 487 for > > > the CANCEL to the UAC? > > > > Neither. > > > > The scenario you set up will play out as follows: > > > > UAC P1 UAS1 UAS2 > > |INVITE | | | > > |------------->| INVITE | | > > | 100 |------------->| | > > |<-------------| | INVITE | > > | |----------------------------->| > > | | 100 | | > > | CANCEL |<-------------| | > > |------------->| | | > > | 200 (CANCEL) | | | > > |<-------------| CANCEL | | > > | |------------->| | > > | | 200 (CANCEL) | | > > | |<-------------| | > > | | 487 (INVITE) | | > > | |<-------------| | > > | | ACK | | > > | |------------->| | > > | | | 200 (INVITE) | > > | 200 (INVITE) |<-----------------------------| > > |<-------------| | | > > | ACK | | | > > |------------->| ACK | | > > | |----------------------------->| > > | | | | > > | | | | > > | | | | > > > > CANCEL is hop-hop. All that a 200 means to a CANCEL > > is that it got to the next hop, not that something > > actually got cancelled. A CANCEL will never recieve > > a 487 response (as you suggest in step 2 above. Those > > only come in responses to requests that got cancelled. > > > > > > Now, for the CANCEL 200 race condition - that's > > effectively what you set up with UAS2 above > > (leave UAS1 out of the diagram). At the end > > of the scenario, UAC knows that > > 1) The next hop got its CANCEL request, and > > 2) It didn't get to the far side in time to > > CANCEL the request (since it got a 200 to > > the INVITE). > > > > Everyone is in sync - no crossing problem. > > > > > > > > > > > >>As I stated previously, if the CANCEL arrives to the server > > > before the > > > >>INVITE, the UAC will not have any way to cancel the > request. Then it > > > >>would have to wait until the INVITE is answered in > order to send a > > > >>BYE... and this can really take very long. > > > >Why can't BYE be sent for an early dialog to terminate > the dialog? > > > > > > This has been discussed before, and the UAC CAN use BYE > to terminate a > > > dialog, assuming it has received a 1xx with a To header tag. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 14:50:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29118 for ; Wed, 31 Oct 2001 14:50:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04602 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 14:50:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04363; Wed, 31 Oct 2001 14:39:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04335 for ; Wed, 31 Oct 2001 14:39:50 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28905 for ; Wed, 31 Oct 2001 14:39:46 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VJdPf17622; Wed, 31 Oct 2001 20:39:25 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VJdOB29322; Wed, 31 Oct 2001 21:39:24 +0200 (EET) Message-ID: <3BE05378.1CA18ECC@lmf.ericsson.se> Date: Wed, 31 Oct 2001 21:39:36 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Romel Khan , "'Robert Sparks'" , Shan Lu , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: Re: [Sip] Bis-05 question: CANCEL References: <6F46FABB90ABD411BD690002B3152FB946713E@lkwmail01> <3BE04AB8.27625D3E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>It's logical and ok for billing to have nothing to do with bis-05, but >>service providers will be the ones to get stuck with any possible billing >>repercussions from these requirements. >> >>By the way, what is the probability that, using UDP, INVITE will be received >>after CANCEL? I assume a very small percentage of the time. Therefore, it >>would be preferrable that CANCEL be sent right away rather than consume >>resources by waiting for provisional responses for a moot reason. How about >>change "CANCEL must" wait for provisional response to "CANCEL should". >> > >Don't you undestand that what the harm that you can produce by being >unable to hang up a call because the CANCEL made it before the INVITE is >much higher than having to wait for a provisional response? First, maybe I don't get the point, but exactly what "harm" could this produce? Second, IF it will be a requirement to wait for the 1xx, then I think it also must be a requirement to send a 1xx in the first plavce (ie "the server MUST send 100/18x/whatever as soon as it receives the INVITE"). Otherwise there MAY be cases (if no 1xx is sent) where the UAC can't terminate the call before it has received the 200 final response... >About the chances of a CANCEL arriving before the INVITE, you only need >one single message lost (the first transmission of the INVITE) and the >caller hanging up in less than half a second... not a so strange >scenario, I believe. Which scenario? Loosing a message, or hanging up in less than half a second? :) Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 14:59:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29309 for ; Wed, 31 Oct 2001 14:59:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04676 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 14:59:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04527; Wed, 31 Oct 2001 14:44:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04496 for ; Wed, 31 Oct 2001 14:44:44 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28985 for ; Wed, 31 Oct 2001 14:44:42 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9VJiEL09751 for ; Wed, 31 Oct 2001 14:44:14 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4SJSXY>; Wed, 31 Oct 2001 19:44:08 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC344F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'Shan Lu'" Cc: "'IETF SIP Mailing List'" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 19:44:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org On the ISDN/PSTN if I have a massive set of timeouts and dropouts across the network for the transmission of a message, then ultimately I could well get a delay of 30 seconds on propagation of the second message, over and above the delay in the propagation of the SETUP/IAM. The answer is that this does not happen very often, so infrequently as to be unnoticeable. If there is a 30s difference in getting messages the clear message through, due to delay in receiving a provision response at the calling UA, then the end to end propagation delay of signalling messages is also of the order of that. Any system that tries to control telecommunications that consistently gives 30s delays in end to end transmission of signalling messages is not going to be used for telecommunications. The user will throw it in the bin and go back to tin cans and string. Most calling users do not even allow a phone to ring for 30s when it is not answered. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Shan Lu[SMTP:shanlu@sentito.com] > Sent: 31 October 2001 19:27 > To: 'Drage, Keith (Keith)' > Cc: 'IETF SIP Mailing List' > Subject: RE: [Sip] Bis-05 question: CANCEL > > The only difference is that in PSTN you don't keep ringing the phone 30s > after the caller has hung up, do you? > > Shan Lu > sentitO Networks > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Drage, Keith (Keith) > > Sent: Wednesday, October 31, 2001 1:27 PM > > To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'Romel Khan' > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > > Subject: RE: [Sip] Bis-05 question: CANCEL > > > > > > None of this supposedly disastrous scenario for the SIP > > environment is any > > different to what happens in the PSTN/ISDN today. If you send > > a call request > > (SETUP/IAM or whatever) with full address into the PSTN/ISDN > > today, and then > > follow it up with a release, the first message will > > invariably reach the end > > terminal (and be processed there) before the second is > > received. There is > > therefore even today the chance that such a call is answered > > before the > > clear is received. > > > > This has been the case for years, and nobody has noticed. > > > > Will it really be a problem for SIP. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > ---------- > > > From: Romel Khan[SMTP:rkhan@net2phone.com] > > > Sent: 31 October 2001 15:26 > > > To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu > > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; > > Jonathan Rosenberg > > > Subject: RE: [Sip] Bis-05 question: CANCEL > > > > > > So the following scenario can happen with SIP bis 05, right? > > > > > > A caller makes a call. An Invite is sent out. Caller hangs > > up right away > > > before any provisional response comes back. So a CANCEL is not sent > > > because > > > provisional response was not received. Callee starts > > ringing although > > > caller > > > has already hung up (very very bizarre!). 180 is sent back > > but gets lost. > > > Callee picks up although caller is gone and a 200 OK is > > sent back (another > > > very bizarre situation). > > > Is it documented in SIP bis05 that the UAC will know to > > send a BYE in this > > > scenario after receiving 200 OK right away and how can it > > be made sure > > > that > > > the caller, who may be long gone, will not get billed? > > > How will fast-connects be handled (UAS sends 200 OK after receiving > > > Invite, > > > and no prov. response sent)? > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > Sent: Wednesday, October 31, 2001 9:26 AM > > > To: 'Christer Holmberg'; Shan Lu > > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > > > Subject: RE: [Sip] Bis-05 question: CANCEL > > > > > > > > > inline > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Tuesday, October 30, 2001 11:40 PM > > > > To: Shan Lu > > > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; > > 'Jonathan Rosenberg' > > > > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > > > > > > > > > > > > > Hi, > > > > > > > > I understand the arguments for buffering. BUT, by waiting for > > > > the first > > > > 1xx we still don't solve the CANCEL/200 race condition. > > > > > > Yes, we've solved this one. More after the answer to the > > > scenario below. > > > > > > > > > > > Also, consider the following case: > > > > > > > > > > > > |------- UAS 1 > > > > UAC --- P1 > > > > |------- UAS 2 > > > > > > > > > > > > Now, the UAC sends an INVITE, which gets forked by P1. P1 > > > > also sends 100 > > > > back to UAC. Then, the UAC decides to terminate the > > setup, so it sends > > > > CANCEL. > > > > > > > > Now, P1 has also received 1xx from UAS 1, so it can send > > the CANCEL > > > > there. > > > > > > > > HOWEVER, P1 has NOT received a 1xx from UAS 2, and it > > won't even do > > > > that. Instead, the UAS 2 returns 200 OK immedeately. So, what > > > > does P1 do > > > > now? Creates a BYE transaction to UAS 2 - and when it receives a > > > > response to that it sends 200 for the CANCEL to the UAC??? > > > > This sounds a > > > > little like B2BUA behaviour to me... > > > > > > Its more than a little like B2BUA - P1 cannot generate > > > a BYE on its own. Once you take that step, you are no > > > longer talking about proxies. > > > > > > > > > > > > > > > AND, the following (easier case) could also have happened in the > > > > scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when > > > > P1 sends a > > > > CANCEL both UAS 1 and UAS 2 have sent 200 - so what does > > P1 do now? > > > > > > > > 1. Create a BYE to both UAS 1 and UAS 2? > > > > > > > > 2. Forward the 200 response for the INVITE to the UAC, and > > > > sends 487 for > > > > the CANCEL to the UAC? > > > > > > Neither. > > > > > > The scenario you set up will play out as follows: > > > > > > UAC P1 UAS1 UAS2 > > > |INVITE | | | > > > |------------->| INVITE | | > > > | 100 |------------->| | > > > |<-------------| | INVITE | > > > | |----------------------------->| > > > | | 100 | | > > > | CANCEL |<-------------| | > > > |------------->| | | > > > | 200 (CANCEL) | | | > > > |<-------------| CANCEL | | > > > | |------------->| | > > > | | 200 (CANCEL) | | > > > | |<-------------| | > > > | | 487 (INVITE) | | > > > | |<-------------| | > > > | | ACK | | > > > | |------------->| | > > > | | | 200 (INVITE) | > > > | 200 (INVITE) |<-----------------------------| > > > |<-------------| | | > > > | ACK | | | > > > |------------->| ACK | | > > > | |----------------------------->| > > > | | | | > > > | | | | > > > | | | | > > > > > > CANCEL is hop-hop. All that a 200 means to a CANCEL > > > is that it got to the next hop, not that something > > > actually got cancelled. A CANCEL will never recieve > > > a 487 response (as you suggest in step 2 above. Those > > > only come in responses to requests that got cancelled. > > > > > > > > > Now, for the CANCEL 200 race condition - that's > > > effectively what you set up with UAS2 above > > > (leave UAS1 out of the diagram). At the end > > > of the scenario, UAC knows that > > > 1) The next hop got its CANCEL request, and > > > 2) It didn't get to the far side in time to > > > CANCEL the request (since it got a 200 to > > > the INVITE). > > > > > > Everyone is in sync - no crossing problem. > > > > > > > > > > > > > > > >>As I stated previously, if the CANCEL arrives to the server > > > > before the > > > > >>INVITE, the UAC will not have any way to cancel the > > request. Then it > > > > >>would have to wait until the INVITE is answered in > > order to send a > > > > >>BYE... and this can really take very long. > > > > >Why can't BYE be sent for an early dialog to terminate > > the dialog? > > > > > > > > This has been discussed before, and the UAC CAN use BYE > > to terminate a > > > > dialog, assuming it has received a 1xx with a To header tag. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 15:36:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00673 for ; Wed, 31 Oct 2001 15:36:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06425 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 15:36:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05465; Wed, 31 Oct 2001 15:17:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05382 for ; Wed, 31 Oct 2001 15:17:36 -0500 (EST) Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29711 for ; Wed, 31 Oct 2001 15:17:37 -0500 (EST) Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1]) by mail.net2phone.com (8.11.5/8.11.5) with ESMTP id f9VKH7f15246; Wed, 31 Oct 2001 15:17:07 -0500 (EST) Received: by mailsvr with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 15:17:35 -0500 Message-ID: <6F46FABB90ABD411BD690002B3152FB9467140@lkwmail01> From: Romel Khan To: "'Drage, Keith (Keith)'" , "'Robert Sparks'" , "'Christer Holmberg'" , Shan Lu , Romel Khan Cc: "'Gonzalo Camarillo'" , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 15:14:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Nope, in PSTN with SS7, you will NEVER EVER have a case that a caller has hung up and the phone still keeps ringing. More bizarre possibility with SIP bis05 is that phone keeps ringing and callee picks up, but the caller has long hung up. In PSTN with SS7, as soon as the caller hangs up, an ISUP REL will be sent (Q.931 DISCONNECT with ISDN). -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Wednesday, October 31, 2001 1:27 PM To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'Romel Khan' Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg Subject: RE: [Sip] Bis-05 question: CANCEL None of this supposedly disastrous scenario for the SIP environment is any different to what happens in the PSTN/ISDN today. If you send a call request (SETUP/IAM or whatever) with full address into the PSTN/ISDN today, and then follow it up with a release, the first message will invariably reach the end terminal (and be processed there) before the second is received. There is therefore even today the chance that such a call is answered before the clear is received. This has been the case for years, and nobody has noticed. Will it really be a problem for SIP. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Romel Khan[SMTP:rkhan@net2phone.com] > Sent: 31 October 2001 15:26 > To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > Subject: RE: [Sip] Bis-05 question: CANCEL > > So the following scenario can happen with SIP bis 05, right? > > A caller makes a call. An Invite is sent out. Caller hangs up right away > before any provisional response comes back. So a CANCEL is not sent > because > provisional response was not received. Callee starts ringing although > caller > has already hung up (very very bizarre!). 180 is sent back but gets lost. > Callee picks up although caller is gone and a 200 OK is sent back (another > very bizarre situation). > Is it documented in SIP bis05 that the UAC will know to send a BYE in this > scenario after receiving 200 OK right away and how can it be made sure > that > the caller, who may be long gone, will not get billed? > How will fast-connects be handled (UAS sends 200 OK after receiving > Invite, > and no prov. response sent)? > > > > > > > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, October 31, 2001 9:26 AM > To: 'Christer Holmberg'; Shan Lu > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > Subject: RE: [Sip] Bis-05 question: CANCEL > > > inline > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, October 30, 2001 11:40 PM > > To: Shan Lu > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg' > > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > > > > > Hi, > > > > I understand the arguments for buffering. BUT, by waiting for > > the first > > 1xx we still don't solve the CANCEL/200 race condition. > > Yes, we've solved this one. More after the answer to the > scenario below. > > > > > Also, consider the following case: > > > > > > |------- UAS 1 > > UAC --- P1 > > |------- UAS 2 > > > > > > Now, the UAC sends an INVITE, which gets forked by P1. P1 > > also sends 100 > > back to UAC. Then, the UAC decides to terminate the setup, so it sends > > CANCEL. > > > > Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL > > there. > > > > HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do > > that. Instead, the UAS 2 returns 200 OK immedeately. So, what > > does P1 do > > now? Creates a BYE transaction to UAS 2 - and when it receives a > > response to that it sends 200 for the CANCEL to the UAC??? > > This sounds a > > little like B2BUA behaviour to me... > > Its more than a little like B2BUA - P1 cannot generate > a BYE on its own. Once you take that step, you are no > longer talking about proxies. > > > > > > > AND, the following (easier case) could also have happened in the > > scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when > > P1 sends a > > CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? > > > > 1. Create a BYE to both UAS 1 and UAS 2? > > > > 2. Forward the 200 response for the INVITE to the UAC, and > > sends 487 for > > the CANCEL to the UAC? > > Neither. > > The scenario you set up will play out as follows: > > UAC P1 UAS1 UAS2 > |INVITE | | | > |------------->| INVITE | | > | 100 |------------->| | > |<-------------| | INVITE | > | |----------------------------->| > | | 100 | | > | CANCEL |<-------------| | > |------------->| | | > | 200 (CANCEL) | | | > |<-------------| CANCEL | | > | |------------->| | > | | 200 (CANCEL) | | > | |<-------------| | > | | 487 (INVITE) | | > | |<-------------| | > | | ACK | | > | |------------->| | > | | | 200 (INVITE) | > | 200 (INVITE) |<-----------------------------| > |<-------------| | | > | ACK | | | > |------------->| ACK | | > | |----------------------------->| > | | | | > | | | | > | | | | > > CANCEL is hop-hop. All that a 200 means to a CANCEL > is that it got to the next hop, not that something > actually got cancelled. A CANCEL will never recieve > a 487 response (as you suggest in step 2 above. Those > only come in responses to requests that got cancelled. > > > Now, for the CANCEL 200 race condition - that's > effectively what you set up with UAS2 above > (leave UAS1 out of the diagram). At the end > of the scenario, UAC knows that > 1) The next hop got its CANCEL request, and > 2) It didn't get to the far side in time to > CANCEL the request (since it got a 200 to > the INVITE). > > Everyone is in sync - no crossing problem. > > > > > > > >>As I stated previously, if the CANCEL arrives to the server > > before the > > >>INVITE, the UAC will not have any way to cancel the request. Then it > > >>would have to wait until the INVITE is answered in order to send a > > >>BYE... and this can really take very long. > > >Why can't BYE be sent for an early dialog to terminate the dialog? > > > > This has been discussed before, and the UAC CAN use BYE to terminate a > > dialog, assuming it has received a 1xx with a To header tag. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 15:56:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01329 for ; Wed, 31 Oct 2001 15:56:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07381 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 15:56:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06640; Wed, 31 Oct 2001 15:39:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06609 for ; Wed, 31 Oct 2001 15:39:36 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00767 for ; Wed, 31 Oct 2001 15:39:35 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VKdTC04794; Wed, 31 Oct 2001 21:39:29 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VKdRB00394; Wed, 31 Oct 2001 22:39:27 +0200 (EET) Message-ID: <3BE0618B.9CD1B7D4@lmf.ericsson.se> Date: Wed, 31 Oct 2001 22:39:39 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Romel Khan CC: "'Drage, Keith (Keith)'" , "'Robert Sparks'" , Shan Lu , "'Gonzalo Camarillo'" , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: Re: [Sip] Bis-05 question: CANCEL References: <6F46FABB90ABD411BD690002B3152FB9467140@lkwmail01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, First, I don't think we should "compare" SIP with ISUP, because we are NOT trying to implement another ISUP, are we? Since we are dealing with a protocol on an IP network, and we don't have the same kind of reliability as a SS7 network, the fact is that we may have packet losses, messages may be delivered in wrong order etc etc. Now, the easiest way to solve this is to always only have one active transaction, ie you don't send any new request before you have received the response from the previous request. Well, I think we all agree that that will NOT work for SIP, especially not during the session setup, where we may have a number of different overlapping requests, maybe also for different early legs. So, since we will have to live with the fact that the things above may occur, I still think we should have mechanisms to handle these scenarios - INSTEAD of trying to define case specific rules to try to prevent them. Just my personal thoughts... Regards, Christer Holmberg Ericsson Finland Romel Khan wrote: > > Nope, in PSTN with SS7, you will NEVER EVER have a case that a caller has > hung up and the phone still keeps ringing. More bizarre possibility with SIP > bis05 is that phone keeps ringing and callee picks up, but the caller has > long hung up. > In PSTN with SS7, as soon as the caller hangs up, an ISUP REL will be sent > (Q.931 DISCONNECT with ISDN). > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, October 31, 2001 1:27 PM > To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'Romel Khan' > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > Subject: RE: [Sip] Bis-05 question: CANCEL > > None of this supposedly disastrous scenario for the SIP environment is any > different to what happens in the PSTN/ISDN today. If you send a call request > (SETUP/IAM or whatever) with full address into the PSTN/ISDN today, and then > follow it up with a release, the first message will invariably reach the end > terminal (and be processed there) before the second is received. There is > therefore even today the chance that such a call is answered before the > clear is received. > > This has been the case for years, and nobody has noticed. > > Will it really be a problem for SIP. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Romel Khan[SMTP:rkhan@net2phone.com] > > Sent: 31 October 2001 15:26 > > To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > > Subject: RE: [Sip] Bis-05 question: CANCEL > > > > So the following scenario can happen with SIP bis 05, right? > > > > A caller makes a call. An Invite is sent out. Caller hangs up right away > > before any provisional response comes back. So a CANCEL is not sent > > because > > provisional response was not received. Callee starts ringing although > > caller > > has already hung up (very very bizarre!). 180 is sent back but gets lost. > > Callee picks up although caller is gone and a 200 OK is sent back (another > > very bizarre situation). > > Is it documented in SIP bis05 that the UAC will know to send a BYE in this > > scenario after receiving 200 OK right away and how can it be made sure > > that > > the caller, who may be long gone, will not get billed? > > How will fast-connects be handled (UAS sends 200 OK after receiving > > Invite, > > and no prov. response sent)? > > > > > > > > > > > > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Wednesday, October 31, 2001 9:26 AM > > To: 'Christer Holmberg'; Shan Lu > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg > > Subject: RE: [Sip] Bis-05 question: CANCEL > > > > > > inline > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Tuesday, October 30, 2001 11:40 PM > > > To: Shan Lu > > > Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg' > > > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > > > > > > > > > Hi, > > > > > > I understand the arguments for buffering. BUT, by waiting for > > > the first > > > 1xx we still don't solve the CANCEL/200 race condition. > > > > Yes, we've solved this one. More after the answer to the > > scenario below. > > > > > > > > Also, consider the following case: > > > > > > > > > |------- UAS 1 > > > UAC --- P1 > > > |------- UAS 2 > > > > > > > > > Now, the UAC sends an INVITE, which gets forked by P1. P1 > > > also sends 100 > > > back to UAC. Then, the UAC decides to terminate the setup, so it sends > > > CANCEL. > > > > > > Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL > > > there. > > > > > > HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do > > > that. Instead, the UAS 2 returns 200 OK immedeately. So, what > > > does P1 do > > > now? Creates a BYE transaction to UAS 2 - and when it receives a > > > response to that it sends 200 for the CANCEL to the UAC??? > > > This sounds a > > > little like B2BUA behaviour to me... > > > > Its more than a little like B2BUA - P1 cannot generate > > a BYE on its own. Once you take that step, you are no > > longer talking about proxies. > > > > > > > > > > > AND, the following (easier case) could also have happened in the > > > scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when > > > P1 sends a > > > CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? > > > > > > 1. Create a BYE to both UAS 1 and UAS 2? > > > > > > 2. Forward the 200 response for the INVITE to the UAC, and > > > sends 487 for > > > the CANCEL to the UAC? > > > > Neither. > > > > The scenario you set up will play out as follows: > > > > UAC P1 UAS1 UAS2 > > |INVITE | | | > > |------------->| INVITE | | > > | 100 |------------->| | > > |<-------------| | INVITE | > > | |----------------------------->| > > | | 100 | | > > | CANCEL |<-------------| | > > |------------->| | | > > | 200 (CANCEL) | | | > > |<-------------| CANCEL | | > > | |------------->| | > > | | 200 (CANCEL) | | > > | |<-------------| | > > | | 487 (INVITE) | | > > | |<-------------| | > > | | ACK | | > > | |------------->| | > > | | | 200 (INVITE) | > > | 200 (INVITE) |<-----------------------------| > > |<-------------| | | > > | ACK | | | > > |------------->| ACK | | > > | |----------------------------->| > > | | | | > > | | | | > > | | | | > > > > CANCEL is hop-hop. All that a 200 means to a CANCEL > > is that it got to the next hop, not that something > > actually got cancelled. A CANCEL will never recieve > > a 487 response (as you suggest in step 2 above. Those > > only come in responses to requests that got cancelled. > > > > > > Now, for the CANCEL 200 race condition - that's > > effectively what you set up with UAS2 above > > (leave UAS1 out of the diagram). At the end > > of the scenario, UAC knows that > > 1) The next hop got its CANCEL request, and > > 2) It didn't get to the far side in time to > > CANCEL the request (since it got a 200 to > > the INVITE). > > > > Everyone is in sync - no crossing problem. > > > > > > > > > > > >>As I stated previously, if the CANCEL arrives to the server > > > before the > > > >>INVITE, the UAC will not have any way to cancel the request. Then it > > > >>would have to wait until the INVITE is answered in order to send a > > > >>BYE... and this can really take very long. > > > >Why can't BYE be sent for an early dialog to terminate the dialog? > > > > > > This has been discussed before, and the UAC CAN use BYE to terminate a > > > dialog, assuming it has received a 1xx with a To header tag. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 16:58:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04081 for ; Wed, 31 Oct 2001 16:58:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11907 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 16:58:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11269; Wed, 31 Oct 2001 16:42:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11237 for ; Wed, 31 Oct 2001 16:42:00 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03668 for ; Wed, 31 Oct 2001 16:42:00 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9VLfvY23256; Wed, 31 Oct 2001 15:41:57 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VLfuu03089; Wed, 31 Oct 2001 15:41:56 -0600 (CST) Received: from lmf.ericsson.se (rmt160211.am.ericsson.se [138.85.160.211]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA15552; Wed, 31 Oct 2001 15:41:53 -0600 (CST) Message-ID: <3BE07517.D4A3@lmf.ericsson.se> Date: Thu, 01 Nov 2001 00:03:03 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Romel Khan CC: "'Drage, Keith (Keith)'" , "'Robert Sparks'" , "'Christer Holmberg'" , Shan Lu , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: Re: [Sip] Bis-05 question: CANCEL References: <6F46FABB90ABD411BD690002B3152FB9467140@lkwmail01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, The problem here is that people are mixing up layers. Take into account that when we run SIP over UDP we are implementing a small transport layer in the SIP (application) layer... more comments inline: Romel Khan wrote: > > Nope, in PSTN with SS7, you will NEVER EVER have a case that a caller has > hung up and the phone still keeps ringing. Actually it can perfectly happen. I make a call and I send an IAM. Then I hung up, so my local exchange sends a REL. However, since there is congestion (due to any reason), MTP2 cannot deliver my REL inmediately. Therefore, until MTP2 does not manage to deliver the REL, the callee's phone is ringing but the caller has hung up. This is exactly the same situation that we are facing with SIP. Since the network is cogested signalling messages are not getting thru. That's why we do not receive the 100 Trying. If the signalling transport works properly, both SIP and ISUP will perform OK. > More bizarre possibility with SIP > bis05 is that phone keeps ringing and callee picks up, but the caller has > long hung up. As I have said, under congestion, this scenario is perfectly possible in both SIP and ISUP. > In PSTN with SS7, as soon as the caller hangs up, an ISUP REL will be sent > (Q.931 DISCONNECT with ISDN). Sending a REL does not ensure that the REL has been received by the other party. If MTP2 cannot send the message the situation is the same as if the UAC cannot send the message until congestion finishes (that is, when the 100 Trying has been received). Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 16:59:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04126 for ; Wed, 31 Oct 2001 16:59:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11953 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 16:59:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11468; Wed, 31 Oct 2001 16:45:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11439 for ; Wed, 31 Oct 2001 16:45:22 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03779 for ; Wed, 31 Oct 2001 16:45:21 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9VLjGY24914; Wed, 31 Oct 2001 15:45:16 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VLjGC09222; Wed, 31 Oct 2001 15:45:16 -0600 (CST) Received: from lmf.ericsson.se (rmt160211.am.ericsson.se [138.85.160.211]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA15861; Wed, 31 Oct 2001 15:45:11 -0600 (CST) Message-ID: <3BE075DD.91B590BA@lmf.ericsson.se> Date: Thu, 01 Nov 2001 00:06:21 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Romel Khan , "'Robert Sparks'" , Shan Lu , "'IETF SIP Mailing List'" , Jonathan Rosenberg Subject: Re: [Sip] Bis-05 question: CANCEL References: <6F46FABB90ABD411BD690002B3152FB946713E@lkwmail01> <3BE04AB8.27625D3E@lmf.ericsson.se> <3BE05378.1CA18ECC@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Christer Holmberg wrote: > > Hi, > > >>It's logical and ok for billing to have nothing to do with bis-05, but > >>service providers will be the ones to get stuck with any possible billing > >>repercussions from these requirements. > >> > >>By the way, what is the probability that, using UDP, INVITE will be received > >>after CANCEL? I assume a very small percentage of the time. Therefore, it > >>would be preferrable that CANCEL be sent right away rather than consume > >>resources by waiting for provisional responses for a moot reason. How about > >>change "CANCEL must" wait for provisional response to "CANCEL should". > >> > > > >Don't you undestand that what the harm that you can produce by being > >unable to hang up a call because the CANCEL made it before the INVITE is > >much higher than having to wait for a provisional response? > > First, maybe I don't get the point, but exactly what "harm" could this > produce? > If you do not think that not being able to hang up a call is harmful then we live in different worlds. > Second, IF it will be a requirement to wait for the 1xx, then I think it > also must be a requirement to send a 1xx in the first plavce bis-05 says that the server transaction MUST send a 100 Trying unless another response will be sent in 200 ms. (ie "the > server MUST send 100/18x/whatever as soon as it receives the INVITE"). > Otherwise there MAY be cases (if no 1xx is sent) where the UAC can't > terminate the call before it has received the 200 final response... > > >About the chances of a CANCEL arriving before the INVITE, you only need > >one single message lost (the first transmission of the INVITE) and the > >caller hanging up in less than half a second... not a so strange > >scenario, I believe. > > Which scenario? Loosing a message, or hanging up in less than half a > second? :) > Both at the same time. Regards, Gonzalo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 17:13:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04687 for ; Wed, 31 Oct 2001 17:13:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12778 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 17:13:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12523; Wed, 31 Oct 2001 17:01:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12494 for ; Wed, 31 Oct 2001 17:01:01 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04275 for ; Wed, 31 Oct 2001 17:01:00 -0500 (EST) From: John.Hearty@level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA16405 for ; Wed, 31 Oct 2001 22:01:03 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA23171 for ; Wed, 31 Oct 2001 22:01:02 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <4GXRTMTJ>; Wed, 31 Oct 2001 15:01:02 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B36FCC@n0214idc1.oss.level3.com> To: sip@ietf.org Date: Wed, 31 Oct 2001 15:00:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] bis-05 transaction definition Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The definition for a transaction was re-worded in bis-05 (lines 889-894). I saw no mention in the changes section and don't recall this discussed, so I'm guessing the intent was to include ACK for 2xx responses to Invite as part of the Invite transaction, and ACK for non-2xx response as a new transaction. If this is the case, a "non-" in front of 2xx on line 894 is missing, and the 2xx on line 893 needs to indicate it is an Invite 2xx rather than a 2xx for any request. Let me know if I am mis-interpreting the intent of the re-wording. Otherwise the first sentence appears to conflict with the last sentence. John Hearty Level3 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 18:19:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05486 for ; Wed, 31 Oct 2001 18:19:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14834 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 18:19:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14213; Wed, 31 Oct 2001 17:58:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14182 for ; Wed, 31 Oct 2001 17:58:20 -0500 (EST) Received: from mail.mediatrix.com (mail.mediatrix.com [66.129.134.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05292 for ; Wed, 31 Oct 2001 17:58:18 -0500 (EST) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id <4WV338NX>; Wed, 31 Oct 2001 17:58:22 -0500 Message-ID: From: Alexandre Charest To: "'IETF SIP Mailing List'" Date: Wed, 31 Oct 2001 17:58:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Little typos in bis05 pdf ABNF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In the bis05 pdf ABNF section, at line 4489 (definition of BAR), at line 4517 (definition of qvalue), at line 4518 (definition of language-range), at line 4521 (definition of AuthenticationInfo), at line 4547 (definition of Server) and at line 4554 (definition of User-Agent), the vertical bar '|' has been replaced by a dash '-'. I think this is a typo. AlexC _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 18:19:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05512 for ; Wed, 31 Oct 2001 18:19:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14850 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 18:19:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14367; Wed, 31 Oct 2001 18:00:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14327 for ; Wed, 31 Oct 2001 18:00:14 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05312 for ; Wed, 31 Oct 2001 18:00:12 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VN0Ff01224; Thu, 1 Nov 2001 00:00:15 +0100 (MET) Received: from ericsson.com (racom044.nrj.ericsson.se [150.236.199.236]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VN0BB02762; Thu, 1 Nov 2001 01:00:12 +0200 (EET) Message-ID: <3BE08273.CCC5D807@ericsson.com> Date: Thu, 01 Nov 2001 01:00:03 +0200 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'sip@ietf.org'" Subject: Re: [Sip] Clarification of bis-05 changes requested References: <475FF955A05DD411980D00508B6D5FB001AC344C@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Keith: The old appendix B has moved to a separate draft: http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-sdp-offer-answer-00.txt /Miguel "Drage, Keith (Keith)" wrote: > > While I accept that the list of changes from the previous version does not > have to be definitive, the current list of changes from -04 to -05 seems > sparse in places. > > In particular I was trying to identify whether the Response-Key and > Encryption headers had been intentionally removed - does that mean they no > longer exist or are they about to pop up in another draft somewhere else? > > Also what is happening to the section that used to exist in -04 (Appendix B) > on the use of SDP. Has it definitely been agreed that this becomes a draft > elsewhere, and if so, where is it? > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 18:45:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05742 for ; Wed, 31 Oct 2001 18:45:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15401 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 18:45:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14940; Wed, 31 Oct 2001 18:29:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14909 for ; Wed, 31 Oct 2001 18:29:43 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05609 for ; Wed, 31 Oct 2001 18:29:41 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9VNS0b7021502; Wed, 31 Oct 2001 18:28:00 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 18:29:14 -0500 Message-ID: From: Jonathan Rosenberg To: "Drage, Keith (Keith)" , "'sip@ietf.org'" Subject: RE: [Sip] Clarification of bis-05 changes requested Date: Wed, 31 Oct 2001 18:29:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, October 31, 2001 1:53 PM > To: 'sip@ietf.org' > Subject: [Sip] Clarification of bis-05 changes requested > > > While I accept that the list of changes from the previous > version does not > have to be definitive, the current list of changes from -04 > to -05 seems > sparse in places. > > In particular I was trying to identify whether the Response-Key and > Encryption headers had been intentionally removed - does that > mean they no > longer exist or are they about to pop up in another draft > somewhere else? > Keith - the two headers were defined in bis-04, but there were no defined algorithms to use them, as PGP had already been deprecated earlier. Thus, they were effectively "garbage collected" in this release. My apoligies for not having included those in the list of changes. > Also what is happening to the section that used to exist in > -04 (Appendix B) > on the use of SDP. Has it definitely been agreed that this > becomes a draft > elsewhere, and if so, where is it? > As has been pointed out, this is extracted to a separate draft. I could have sworn I put that into the changes section, but clearly did not. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > Keith > > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 18:45:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05756 for ; Wed, 31 Oct 2001 18:45:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15415 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 18:45:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14979; Wed, 31 Oct 2001 18:29:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14942 for ; Wed, 31 Oct 2001 18:29:47 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05611 for ; Wed, 31 Oct 2001 18:29:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9VNS2b7021505; Wed, 31 Oct 2001 18:28:02 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 18:29:16 -0500 Message-ID: From: Jonathan Rosenberg To: Christer Holmberg , Bob Penfield Cc: "'IETF SIP Mailing List'" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 18:29:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, October 31, 2001 12:39 PM > To: Bob Penfield > Cc: 'IETF SIP Mailing List' > Subject: Re: [Sip] Bis-05 question: CANCEL > > > > Hi, > > >>I understand the arguments for buffering. BUT, by waiting > for the first > >>1xx we still don't solve the CANCEL/200 race condition. > >> > > > >The solution to the CANCEL/200 race condition has always > been for the UAC to > >be prepared to ACK and BYE if it gets a 200 instead of a > 487. There is no > >difference here. The UAC must always wait for the final > response to the > >INVITE. > > I KNOW what the solution is. What I am saying is that since we DO have > to THAT case into consideration in any case, we can use the SAME > mechanism if we receive a 200 to an INVITE we have tried to > CANCEL - ie > we simply ACK and BYE it. CANCEL is not the same thing as BYE. CANCEL terminates *all* pending branches, BYE terminates a specific one. As such, the UAC would need to continue to BYE individual 1xx as they arrive, until it has finally received a 1xx from all UAS that got the INVITE (and some may never send a 1xx), or gets a final response. This can potentially take quite a while - resulting in the phones on the callee sides ringing for quite some time. That is unacceptable, IMHO. > > My point is: does it really matter if the CANCEL reaches the > UAS before > the INVITE, OR if the CANCEL reaches the UAS after the 200 has been > sent? Absolutely it does. The 2xx will trigger CANCELs at proxies on all other branches, which will either generate a final response to the INVITE (487 usually), or do nothing if a final response is coming. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 19:36:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06101 for ; Wed, 31 Oct 2001 19:36:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA16484 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 19:36:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15903; Wed, 31 Oct 2001 19:16:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15873 for ; Wed, 31 Oct 2001 19:16:36 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05947 for ; Wed, 31 Oct 2001 19:16:36 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA10EJb7021657; Wed, 31 Oct 2001 19:14:19 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 19:15:33 -0500 Message-ID: From: Jonathan Rosenberg To: John.Hearty@level3.com, sip@ietf.org Subject: RE: [Sip] bis-05 transaction definition Date: Wed, 31 Oct 2001 19:15:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > Sent: Wednesday, October 31, 2001 5:01 PM > To: sip@ietf.org > Subject: [Sip] bis-05 transaction definition > > > > The definition for a transaction was re-worded in bis-05 > (lines 889-894). For my own personal sanity, please refer to line numbers in the PDF or PS. Those have explicit line number markings. Line 889-894 defines transactions in the .txt version only. > I saw no mention in the changes section and don't recall this > discussed, so > I'm guessing the intent was to include ACK for 2xx responses > to Invite as > part of the Invite transaction, and ACK for non-2xx response as a new > transaction. No, no, no! Its the opposite. ACK for 2xx is a *different* transaction, ACK for non-2xx is the *same* transaction. This is directly tied to the hop by hop nature of ACK for non-2xx as compared to the end to end nature of 2xx and its ACK. However, you are right that a non- is missing in front of the first 2xx on line 637. I will correct that. This change is actually just a model change, not a behavioral one. It was done to present SIP in a more cleanly layered way. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 20:00:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06492 for ; Wed, 31 Oct 2001 20:00:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17396 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 20:00:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16695; Wed, 31 Oct 2001 19:45:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16604 for ; Wed, 31 Oct 2001 19:45:27 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06216 for ; Wed, 31 Oct 2001 19:45:26 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fA10jNV11319; Wed, 31 Oct 2001 19:45:27 -0500 (EST) Message-ID: <3BE09B23.6A1295B@cs.columbia.edu> Date: Wed, 31 Oct 2001 19:45:23 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Mpierce1@aol.com'" , sip@ietf.org Subject: Re: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05 References: <313680C9A886D511A06000204840E1CF0111A7B7@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > > I have been, and am still very interested in being able to implement > what is called MultiLevel Priority and Pre-emption in SIP. As you > may recall, Jim Polk has made several proposals on this subject. > > The current priority levels are advisory, the values are not defined, > and the current definition allows additional tokens to be used. I would > like to propose that the next revision, bis-06 deprecate the current > token values and substitute the 791 values. I believe that, as the old > ones are indeed advisory, that any existing implementations would not break. I'm opposed to that. The original values reflect "human communications priorities", not network priorities. The RFC 791 priorities are 111 - Network Control 110 - Internetwork Control 101 - CRITIC/ECP 100 - Flash Override 011 - Flash 010 - Immediate 001 - Priority 000 - Routine Unless you work for the military, they are essentially meaningless to normal users. Anybody know what ECP is :-)? Since we suffer no shortage of header names, I would suggest that we have two different sets, one new header for "communications resource priority" (based on RFC 791 and/or the ones suggested by Jim Polk) and the existing Priority header for "human precedence", using the existing naming scheme. Usually, the two are closely related, but may not necessarily be. For example, most calls, from a network perspective, may be "Routine", but I may well consider it "High" priority for the receiving user. I've heard that 791-style values are often assigned based on military rank, so it could even be that a four-star general makes a "non-urgent" call on a "Flash" circuit. Changing names is not a good idea in general since existing implementations may translate them into local languages (and leave unrecognized names alone). > > If that is not acceptable, I'd propose that we ADD the RFC 791 tokens > to the existing tokens, with language explaining what happened. > > Brian > > > > > Why was the list of priorities taken from RFC 2076 rather > > than from RFC 791? > > RFC 2076 was informational and copied the list from RFC 1327 > > (which was > > obsoleted by RFC 2156), They addressed mapping between X.400 > > and RFC 822, but > > RFC 822 did not mention any such values. RFC 791 (and > > appropriate existing > > telephony standards) should form the basis of the priority > > definition field > > in SIP. > > > > Also, there needs to be an explicit statement concerning the > > order of the > > present and the new values. There is no order specified for > > the current set. > > Different people would come to different conclusions about > > the relative order > > of "Routine" and "non-urgent". It needs to state that the > > current four values > > are in the descending order "emergency, urgent, routine, and > > non-urgent". The Good idea. That clearly is needed for any set. > > order of the 5 new values is as defined in RFC 791 and > > applicable standards. > > Also, there should be no defined relation between the current > > set and the new > > added set. It is not expected that they would be used > > together, but if they > > are, it is a local issue on how to handle them. > > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 20:00:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06555 for ; Wed, 31 Oct 2001 20:00:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17591 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 20:00:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16591; Wed, 31 Oct 2001 19:44:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16560 for ; Wed, 31 Oct 2001 19:44:22 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06211 for ; Wed, 31 Oct 2001 19:44:21 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id fA10hSc76800; Wed, 31 Oct 2001 19:43:28 -0500 (EST) Reply-To: From: "Brett Tate" To: "'Christer Holmberg'" Cc: "'IETF SIP Mailing List'" Subject: RE: [Sip] Bis-05 question: CANCEL Date: Wed, 31 Oct 2001 19:44:53 -0500 Message-ID: <000301c1626e$6c5ea0b0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BE05378.1CA18ECC@lmf.ericsson.se> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > >Don't you undestand that what the harm > >that you can produce by being > >unable to hang up a call because the > >CANCEL made it before the INVITE is > >much higher than having to wait for a > >provisional response? > > First, maybe I don't get the point, but > exactly what "harm" could this produce? Otherwise a UAS could continue to ring and/or stream ringback/voice for longer amounts of time. However since this situation still can occur for UAC and/or proxy failure, it only partially solves the problem. I think that the bis-05 made an attempt to address some of the race conditions that can occur in SIP. It is now up to the SIP community to provide comments. One alternative is to queue the CANCEL at UAS/proxy waiting for the associated request. Another alternative is for SIP devices to actually start using the Expires header and/or the UAS to remain in ringing for a "maximum" time. I assume that most UAS implementations will not allow a call to remain in alerting state any longer than 3 minutes unless they are trying to use 182 type functionality. > Second, IF it will be a requirement to > wait for the 1xx, then I think it > also must be a requirement to send a 1xx > in the first plavce (ie "the > server MUST send 100/18x/whatever as soon > as it receives the INVITE"). Section 17.2.1 already mentions "MUST generate 100 response" if the UAS can't respond within 200ms. > Otherwise there MAY be cases > (if no 1xx is sent) where the UAC can't > terminate the call before it has > received the 200 final response... Yes. A malicious server could intentionally delay sending a 1xx in an attempt to help produce a billing situation by delaying the ability for the originator to CANCEL the request. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 23:33:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10565 for ; Wed, 31 Oct 2001 23:33:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA21722 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 23:33:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21340; Wed, 31 Oct 2001 23:17:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21309 for ; Wed, 31 Oct 2001 23:17:31 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10142 for ; Wed, 31 Oct 2001 23:17:30 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA14FHb7022497; Wed, 31 Oct 2001 23:15:17 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 23:16:32 -0500 Message-ID: From: Jonathan Rosenberg To: Christer Holmberg , Henning Schulzrinne Cc: sip@ietf.org Subject: RE: [Sip] Removal proposal: Password in SIP-URL Date: Wed, 31 Oct 2001 23:16:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, October 31, 2001 12:52 PM > To: Henning Schulzrinne > Cc: sip@ietf.org > Subject: Re: [Sip] Removal proposal: Password in SIP-URL > > > > Hi, > > >If my recollection is correct, this suggestion has been discussed > >before, at least once, and been rejected. Apparently, people do > >implement it; the cost is essentially zero. (A header > wouldn't add any > >security benefit, but would make including the password, > e.g., for a SIP > >URL on a secure, private web page for friends, much more painful and > >prone to errors.) > > Fair enough. However, if encryption is used, would be easier > to encrypt > a single header, because it could be encrypted together with > the rest of > the end-to-end headers (unless some proxy needs that password, of > course). If you are bothering with real security, then use a real authentication mechanism. The password in the URI is a mega-cheap, mega-unsecure mechanism. In any case, as Henning has pointed out, it is in use and therefore can't really be deprecated. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Oct 31 23:50:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10739 for ; Wed, 31 Oct 2001 23:50:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA21823 for sip-archive@odin.ietf.org; Wed, 31 Oct 2001 23:50:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21785; Wed, 31 Oct 2001 23:35:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21754 for ; Wed, 31 Oct 2001 23:35:57 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10606 for ; Wed, 31 Oct 2001 23:35:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.156]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA14Y7b7022543; Wed, 31 Oct 2001 23:34:07 -0500 (EST) Message-ID: <3BE0D10A.CE8B6669@dynamicsoft.com> Date: Wed, 31 Oct 2001 23:35:22 -0500 From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: brett@broadsoft.com, "'Christer Holmberg'" , "'IETF SIP Mailing List'" Subject: Re: [Sip] Bis-05 question: CANCEL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There may be a third option that I don't remember having been discussed, namely that the client sends the CANCEL immediately but the server just sliently drops it if it cannot associate it with a request. That is, it doesn't respond and doesn't install transaction state. The client will continue retransmitting CANCEL and the original request in parallel (as per usual) and the CANCEL will continue to be dropped by the server until the original request is actually received. Same procedure would apply to proxy servers. This will no doubt be violently hated by some and I'm not necessarily proposing it anyway ;). Apart from treating CANCEL even more specially than is already the case it means a UAS might ring the phone even though the call was cancelled. Although actually, that should be no worse than if the INVITE has been received immediately and no worse than waiting for a 1xx. Anders Jonathan Rosenberg wrote: > > > > > One alternative is to queue the CANCEL > > at UAS/proxy waiting for the associated > > request. > > Right. The issue with that is that is that it opens a DoS attack. CANCEL > can't be authenticated like other requests since its hBh. Thus, its > authenticated by having it come from the same place the request came from > (and so tls, for example, could be used). This means you trust it if you > trust the request its cancelling. If you buffer at the server, you would > have to buffer the cancel even before an authenticated request arrived. THis > means that someone can send CANCEL to establish state at the server, and > then never send a corresponding request. There is no easy way to defeat this > except to prevent it as we have proposed. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip