Subject: [MMUSIC] Connection-Precon-01 question

From: "James M. Polk" <[email-masked]>
Date: Fri, 03 Dec 2004 12:58:44 -0600

Gonzalo

This is a follow up question along the same lines to what I sent on 11/8.

I thought the idea of preconditions was that they need to be met prior to 
session establishment. I believe this is when the precondition state table 
is identical in both UAs. I do not believe your example in this ID shows 
this to be true prior to transmitting the 180. Shouldn't your UPDATE 
message have the a=curr line of:

         a=curr:conn e2e <something>
         a=des:conn mandatory e2e sendrecv

and not "none" as your examples has (maybe this should be "send" only since 
A has its radio up at this time)?

Further, shouldn't the 200 OK to that UPDATE (or some other message) have 
the following A lines:

         a=curr:conn e2e sendrecv
         a=des:conn mandatory e2e sendrecv

as this would show the precondition conn has been met in both directions?

My confusion is that your precondition is looking for the conn attribute to 
meet the current condition of "e2e sendrecv", and your example does not 
have this prior to showing everything is met and to progress to the 180 
(meaning preconditions have been met).

All this said, I understand you are changing the state in the A line:

         a=setup

attribute along the way. You just do not seem to be addressing the "a=curr" 
condition.

Or am I missing something here?

>X-BrightmailFiltered: true
>X-Brightmail-Tracker: AAAAAA==
>X-BrightmailFiltered: true
>X-Brightmail-Tracker: AAAAAA==
>X-Ironport-AV: i="3.87,122,1099296000";
>    d="scan'208"; a="30556544:sNHT22722228"
>To: [email-masked]
>From: [email-masked]
>Date: Fri, 03 Dec 2004 07:14:52 -0500
>Cc: [email-masked]
>Subject: I-D ACTION:draft-ietf-mmusic-connection-precon-01.txt
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.5
>Reply-To: [email-masked]
>List-Id: i-d-announce.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>         <mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>X-PMX-Version: 4.7.0.111621
>X-from-outside-Cisco: 128.107.234.204
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Multiparty Multimedia Session Control 
>Working Group of the IETF.
>
>         Title           : Connection-Establishment Preconditions in the 
> Session
>                           Initiation Protocol (SIP)
>         Author(s)       : G. Camarillo
>         Filename        : draft-ietf-mmusic-connection-precon-01.txt
>         Pages           : 8
>         Date            : 2004-12-2
>
>This document defines the connection-establishment precondition type
>    for the SIP preconditions framework. Connection-establishment
>    preconditions are met when a transport connection (e.g., a TCP
>    connection) is successfully established between two endpoints.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connection-precon-01.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>[email-masked] with the word unsubscribe in the body of the 
>message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-mmusic-connection-precon-01.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-mmusic-connection-precon-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>-------------------------------------------------------------------------
>CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
>-------------------------------------------------------------------------
>In order to maintain computing infrastructure integrity, Cisco Systems
>Enterprise Messaging Services and InfoSec teams have set a mail policy
>disallowing executable attachments in email.
>
>This message contained an executable attachment type that is prohibited
>by this policy. The attachment has been removed from this message and
>copied to quarantine by our systems. It will be held in quarantine for
>seven days in the event that the content needs to be retrieved.
>
>Please be aware many viruses attempt to look like legitimate email or
>notifications from anti-virus systems. We will clearly mark a seperation
>between our notifications and the original email as follows:
>
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
>
>For further reference information about viruses and email antivirus
>efforts within Cisco, please visit:
>
>http://wwwin.cisco.com/it/ems/services/antiviral
>
>If your concern isn't addressed by the information in this notification
>or the above web page, you may open a support request:
>
>http://wwwin.cisco.com/support/
>
>Select "Messaging", "Email-Related", "Mail Routing"
>
>Please include in the text of your case the following information:
>
>* Full headers of the message. Documentation on displaying the full
>headers is available at this URL:
>
>http://wwwin.cisco.com/support/library/faqs/solution002471.html
>
>* This unique quarantine identifier: iB3HpA0o026059
>
>If the matter is urgent, you may follow up by calling one of the below
>referenced numbers. Please make every effort to provide the above
>requested information via the support web tool prior to calling as it
>will greatly aid the resolution of your issue.
>
>Americas:
>1 408 526 8888
>
>Asiapac
>+61 2 8446 8888
>
>EMEA
>+31 20 485 4888
>
>Japan
>+81 3 5549 6888
>
>US (Toll Free)
>1| 800| 888| 8187| (ext.68888)
>
>Thank you for your cooperation,
>
>Enterprise Messaging Services
>Cisco Systems, Inc
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/i-d-announce

cheers,
James

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

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 14 Dec 2004 11:48:20 +0200

Hi James,

> I thought the idea of preconditions was that they need to be met prior 
> to session establishment. I believe this is when the precondition state 
> table is identical in both UAs.

The tables do not actually need to be the same in both UAs. The tables 
that need to be equal are the table showing the current status and the 
table showing the desired status of the preconditions. Furthermore, in 
our case, the tables need only to be equal at the UAS. That's why the 
UAC does not ask for updates on the status. Once the UAS knows that both 
tables are equal, it resumes session establishment without explicitly 
informing the UAC.

In this example, the UAS receives an INVITE that says: "do not alert the 
user until the TCP connection is established".

The rest of the SIP messages exchanged between both ends do not have 
anything to do with the precondition. They have to do with establishing 
the TCP connection.

Once the TCP connection is established, the precondition is met. Now the 
UAS could send a SIP message to the UAC saying "the current status is 
now sendrecv so I will now resume session establishment"... but the UAS 
does not actually need to do this, because the 180 Ringing will inform 
the UAC anyway that session establishment has resumed. That's why you do 
not see any message with "curr:conn e2e sendserv" in the flow.

Note that when dealing with this type of precondition, UAs usually get 
local information on the status of the connection. That is, the UAs know
that the TCP connection is established because they gets this 
information from their own socket. That's why we do not usually need to 
use SIP to inform the other end about this type of event.

In any case, if you want me to clarify something in the text let me know 
and I will do it.

Thanks,

Gonzalo