headers
Jonathan Rosenberg | 1 May 2003 05:15

Re: Thoughts on GRUUs, URI leasing and embedded route headers

inline.

Christer Holmberg wrote:
> Hi,
> 
> 
>>>To make this work, it is assumed that requests sent in the backward
>>>direction really will be directed via the proxy which issued the
>>>leased URI (unless the proxy is able to "share" the information with
>>>other proxies). So, won't we have the same problem with the
>>>Record-Route URI that you now try to solve for the Contact URI - ie
>>>we want to make sure that requests reach a specific node, and not
>>>just any node within a specific user domain?
>>
>>No.
>>
>>Just because I ask a specific server for a URI that is routable in the
>>domain, does not meant that requests have to go to that specific server.
>>  It is a requirement on the administrator of the domain to guarantee
>>that the URI will route to the UA instance when used by anyone from
>>anywhere. This will frequently require coordinated routing policies
>>throughout the domain. Thats fine. Thats why you need to ask for the
>>name - to make sure what you get is consistent with those routing policies.
> 
> 
> Ok, but assume that proxy A still wants a request to be sent via it. Now, it
> can do so by inserting its IP address in the Record-Route URI, but aren't the
> problems them the same as if the UA would insert its IP address in the Contact?

The problem GRUUs are trying to solve is that a UA wants a URI that it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 1 May 2003 05:24

Conferencing Framework open issue: scope of data which is manipulated by CPCP

Eric raised an issue in his comments on conf-fw, to which I replied:

>> Also, w.r.t. section 5.8.2, I would really hope that CPCP is SIP:
>> I'm really hesitant to have to implement all the same protocol
>> actions with two different protocols "just because."  Let's pick
>> one and run with it.
> 
> 
> See above discussion on why these are just not the same. In the case
> of conference participants, you will basically learn them as the
> result of a full-state update generated by a subscription to the
> conference state.  CPCP, being a data transaction protocol, would
> also allow you to directly query for the list. Just because there is
> this sliver of overlap does not mean that they are the same protocol.
> 

My response is wrong. In the current design, you cannot use CPCP to 
access any of the focus state, such as the current participant list. It 
is strictly viewed as a protocol for manipulated the conference POLICY.

This leads to the question - is this sensible? On one hand, one would 
expect that a protocol for accessing state of the conference should give 
you access to ALL of the state, not just the subset which is defined as 
policy. On the other hand, as Eric points out, conference policy and 
conference state are very different. Indeed, they may likely reside in 
entirely different servers in the network. One can imagine using an 
external DB to hold the policy, whereas focus state is in-memory 
soft-state. Thus, using the same protocol to access them may be 
complicated to support.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 1 May 2003 05:32

Re: CPCP and SIP {conferencing}

Sorry for not responding to these questions earlier. Some answers inline:

Arjun Roychowdhury wrote:
> Reading 
> http://www.ietf.org/internet-drafts/draft-levin-sipping-conferencing-requirements-03.txt
>  and 
> http://www.ietf.org/internet-drafts/draft-koskelainen-sipping-conf-policy-req-00.txt
>  in conjunction,
> 
> it seems both CPCP and SIP have similar requirements and the reqts
> listed in the above two drafts to a great extent can mix with each
> other. This probably is a good  thing since that means SIP can meet
> many of CPCP's requirements.
> 
> But it does not clarify my confusion below:
> 
> In addition, framework-01, for each scenario lists a SIP way and a
> CPCP wa
> 
> Even though SIP may finally land up doing a lot of what is required
> by CPCP,  looking at the framework-01 diagram Figure 2, the interface
> between Participant and Focus is different from the interface between
> Participant and Conference Policy server.
> 
> However, when I read petri's, jonathan's and orit's drafts in
> conjunction, I see these two interfaces sparring in the same ring.
> 
> I am somewhat confused. Where does the design team consider CPCP to
> stop (Participant - CPS) and SIP dialog to start (Participant to
> Focus) ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 1 May 2003 05:09

Re: conf: comments on draft-rosenberg-sipping-conferenc ing-framework-01


Marjou Xavier wrote:
> Hello,
> 
> Something is not clear to me : is CPCP really mandatory to perform
> something as "simple" as calling many recipients via a focus (adhoc
> conference).

In an ad-hoc conference, the focus resides with one of the endpoints. 
Therefore, an internal interface can be used to instruct the focus to 
call out to additional users. So, in the case of ad-hoc, something as 
"simple" as mass invitation does not require CPCP.

With a centralized conference server, a client can use a series of REFER 
requests to bring new users into the conference. This is described in 
the document as a SIP mecahnism for adding users. However, for a large 
number of invitations, this is really inefficient, and thus a real 
control protocol like CPCP is needed.

> In my opinion, it should be as simple as sending an
> e-mail to multiple recipients (Of course, having everybody in the
> "To" header is not possible in SIP, but having another header for
> giving the list of recipients whould be very nice).

Its not as simple as that. How would you report the results of that back 
to the sender?

-Jonathan R.
--

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 1 May 2003 05:43

Re: Comments on draft-rosenberg-sipping-conferencing-framework-01.txt

I was combing back through the SIP/SIPPING list to make sure all 
conferencing framework comments and issues were addressed, and I noticed 
that there was no response to this.

The design team considered whether or not to consider conferences that 
were split amongst multiple focuses, where the focuses were actively 
communicating in order to make the whole thing appear as a single 
conference. This is a very hard problem, and given the scope of the work 
already on the table, we ruled it out of scope.

You can have one focus be a member of another conference. That requires 
no standardization, since a focus is just a UA. That seemed to get us 
enough functionality for free, that the more complex case wasnt worth 
the cost.

-Jonathan R.

Zon-Yin Shae wrote:
> 
> 
> 
> Overall the draft looks good.  I wish this conference frame work can be
> extended to cover the following enterprise/service conferencing scenario:
> 
> When an application need a conference service, it only creates a conference
> ID (and its associated policy).  By the time the application does not know
> (does not want to or can not specify) which conference service ( Focus) to
> use.   Moreover,  it is desired for the performance and scalability that a
> set of Focuses should work collaboratively to perform the distributed
> conference service.  For example, 20 participants in a conference,   10 in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rosen, Brian | 1 May 2003 15:33

RE: Conferencing Framework open issue: scope of data wh ich is manipulated by CPCP

Generally I agree that state and policy are separate.
OTOH, I think the vast majority of implementations will have
them in the same implementation.  I think the design should
allow the possibility of the functions being split, but
be optimized when they are the same entity.  That means they
should have nearly 100% overlap on representation of data
and protocol machinery.  

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen <at> dynamicsoft.com]
> Sent: Wednesday, April 30, 2003 11:24 PM
> To: sipping
> Subject: [Sipping] Conferencing Framework open issue: scope of data
> which is manipulated by CPCP
> 
> 
> Eric raised an issue in his comments on conf-fw, to which I replied:
> 
> >> Also, w.r.t. section 5.8.2, I would really hope that CPCP is SIP:
> >> I'm really hesitant to have to implement all the same protocol
> >> actions with two different protocols "just because."  Let's pick
> >> one and run with it.
> > 
> > 
> > See above discussion on why these are just not the same. In the case
> > of conference participants, you will basically learn them as the
> > result of a full-state update generated by a subscription to the
> > conference state.  CPCP, being a data transaction protocol, would
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 May 2003 21:25
Picon
Favicon

I-D ACTION:draft-ietf-sipping-conferencing-framework-00.txt

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

	Title		: A Framework for Conferencing with the Session 
                          Initiation Protocol
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sipping-conferencing-framework-00.txt
	Pages		: 39
	Date		: 2003-5-1
	
The Session Initiation Protocol (SIP) supports the initiation,
modification, and termination of media sessions between user agents.
These sessions are managed by SIP dialogs, which represent a SIP
relationship between a pair of user agents. Because dialogs are
between pairs of user agents, SIP's usage for two-party
communications (such as a phone call), is obvious. Communications
sessions with multiple participants, generally known as conferencing,
are more complicated. This document defines a framework for how such
conferencing can occur. This framework describes the overall
architecture, terminology, and protocol components needed for multi-
party conferencing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-framework-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,
(Continue reading)

Permalink | Reply | 0 comments |
headers
aki.niemi | 6 May 2003 12:03
Picon

RE: Commentary on draft-niemi-sipping-event-throttle-reqs

Hi Dean,

Thanks a lot for the comments. I'll have some answers inline, and will edit the draft to also reflect your suggestions.

 > -----Original Message-----
 > From: ext Dean Willis [mailto:dean.willis <at> softarmor.com]
 > Sent: 25 April, 2003 04:56
 > To: sipping <at> ietf.org; Niemi Aki (NMP/Helsinki)
 > Cc: jdrosen <at> dynamcisoft.com; David Oran
 > Subject: Commentary on draft-niemi-sipping-event-throttle-reqs
 > 
 > 
 > 
 > At the last meeting, we agreed (well, actually Rohan 
 > volunteered us) that we
 > would look at the event throttling requirements draft, and 
 > that at least a
 > couple of us would post discussions before we considered 
 > taking it on as a
 > WG effort. So here's my try at it.
 > 
 > The given draft is:
 > 
 > http://www.ietf.org/internet-drafts/draft-niemi-sipping-event
 > -throttle-reqs-
 > 01.txt
 > 
 > 
 > Overall, I think that developing an event throttling 
 > mechanism is a good
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marjou Xavier | 6 May 2003 18:57
Picon

RE: conf: comments on draft-rosenberg-sipping-conferenc ing-framework-01


>> Something is not clear to me : is CPCP really mandatory to perform
>> something as "simple" as calling many recipients via a focus (adhoc
>> conference).

> In an ad-hoc conference, the focus resides with one of the endpoints. 
> Therefore, an internal interface can be used to instruct the focus to 
> call out to additional users. So, in the case of ad-hoc, something as 
> "simple" as mass invitation does not require CPCP.

>> With a centralized conference server, a client can use a series of REFER 
>> requests to bring new users into the conference. This is described in 
>> the document as a SIP mecahnism for adding users. However, for a large 
>> number of invitations, this is really inefficient, and thus a real 
>> control protocol like CPCP is needed.

Is a CPCP body inside a SIP INVITE acceptable ? 
(I would like to avoid an additional round-trip delay for a CPCP request before the SIP request)

Then we would also have an intermediate solution for those who want that "CPCP is SIP" : CPCP would be
"inside" SIP (like SDP)

>> In my opinion, it should be as simple as sending an
>> e-mail to multiple recipients (Of course, having everybody in the
>> "To" header is not possible in SIP, but having another header for
>> giving the list of recipients whould be very nice).

> Its not as simple as that. How would you report the results of that back 
> to the sender?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 7 May 2003 13:14
Picon
Favicon

I-D ACTION:draft-umschaden-smime-midcom-sip-proxy-00.txt

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

	Title		: End-to-end Security for Firewall/NAT Traversal within 
                          the Session Initiation Protocol (SIP)
	Author(s)	: K. Umschaden et al.
	Filename	: draft-umschaden-smime-midcom-sip-proxy-00.txt
	Pages		: 37
	Date		: 2003-5-6
	
This document describes an extension for the Session Initiation 
Protocol (SIP), which enables end-to-end security of the Session 
Description Protocol (SDP) together with firewall/Network Address 
Translation (NAT) traversal. This solution relies on Secure 
Multipurpose Internet Mail Extension (S/MIME) and the middlebox 
communications (MIDCOM) protocol. The user authorises a proxy server 
to encrypt the session description on behalf of the user. The proxy 
determines the capabilities of the receiving party and encrypts the 
SDP for a SIP proxy server in the receiving domain. Using MIDCOM, 
each proxy can dynamically control its firewall to open pinholes or 
request NAT bindings for the media flows. As long as each end-user 
may contact its trustworthy SIP proxy via a secure connection and 
authorise this proxy to encrypt the signalling data, the session 
information is secured end-to-end.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-umschaden-smime-midcom-sip-proxy-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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane