headers
Miguel Garcia | 1 Oct 2006 12:50
Picon

Re: URI list for INVITE

Hi Darshan:

The mechanism described in draft-ietf-sip-uri-list-conferencing does 
what you describe, at least at the high-level: It allows a user to send 
a single INVITE request to a URI-list server (which is effectively a 
conference server), to set up a conference with a number of invitees.

However, it seems from your e-mail that you want something else than 
this function. Use case 1 does not end up in setting up a conference, so 
you don't need a conference server. So it looks like something different 
in essence.

The three cases that you are describing imply two different mechanisms: 
one to carry the list of invitees, the other to carry a strategy (or 
policy) to contact those invitees e.g., whether to use sequential, 
parallel, or a mixed strategy.

So, I think what is missing from draft-ietf-sip-uri-list-conferencing is 
a mechanism where the sender of the request can convey a policy to 
contact those URIs. Then it is up to the URI-list server to accept the 
policy or not. This policy conveyance seems to be an additional building 
block that the mentioned draft. It may have some parallelism with the 
fork-directive of the caller preferences (RFC 3841).

/Miguel

Darshan Bildikar wrote:
> List,
> 
> I have recently gone through three drafts that I found interesting
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kyzivat | 2 Oct 2006 04:28
Picon
Favicon

Re: WGLC review of draft-ietf-sipping-dialogusage-03

I'd like to comment further on REGISTER.

As far as I can tell, the relationship between REGISTER and dialogs is 
that both use Call-ID. I don't believe 3261 or any other RFC actually 
uses the term "dialog" in relationship to registration. IMO it would be 
best to refrain from even hinting that there is any such relationship. I 
am inclined to think REGISTER should not even be mentioned in this draft.

	Paul

Vijay K. Gurbani wrote:
> Draft: draft-ietf-sipping-dialogusage-03
> Reviewer:  Vijay K. Gurbani <vkg <at> lucent.com>
> Review Date: Sept. 29, 2006
> Review Deadline:  Oct. 2, 2006
> Status: WGLC
> 
> Summary:
> This draft is basically ready for publication, but has nits that should
> be fixed before publication.
> 
> Detailed review:
> This document posits that multiple dialog usage should be avoided simply
> because its use was never envisioned in the protocol (SIP).  As a
> result, the use of multiple dialogs today is rife with error cases that
> are not canonicalized anywhere (and this draft attempts to document some
> of these), nor does the working group has any substantive experience in
> other cases where multiple dialog usage may be employed (e.g., use of
> multiple dialogs with rfc3891, the "Replaces" header.)
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dale.Worley | 2 Oct 2006 04:51
Picon

Re: WGLC review of draft-ietf-sipping-dialogusage-03

   From: Paul Kyzivat <pkyzivat <at> cisco.com>

   As far as I can tell, the relationship between REGISTER and dialogs is 
   that both use Call-ID. I don't believe 3261 or any other RFC actually 
   uses the term "dialog" in relationship to registration. IMO it would be 
   best to refrain from even hinting that there is any such relationship. I 
   am inclined to think REGISTER should not even be mentioned in this draft.

I'd say we better mention REGISTER or someone will assume things that
we don't want.

I've used the term "quasi-dialog" for the series of REGISTERs that
share a Call-Id.  They share some of the properties of a dialog -- a
common Call-Id and similar semantics for CSeq -- but they definitely
do not share some others -- particularly having a route-set, and so
all requests are routed as initial requests, not mid-dialog requests.
Calling this out in detail will reduce future misunderstandings by
implementors.

And of course we should vigorously specify that a REGISTER
"quasi-dialog" is not to be shared (its Call-Id is not to be used)
with any other purpose.

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vijay K. Gurbani | 2 Oct 2006 06:42
Picon
Favicon

Re: WGLC review of draft-ietf-sipping-dialogusage-03

Paul Kyzivat wrote:
> I'd like to comment further on REGISTER.
> 
> As far as I can tell, the relationship between REGISTER and dialogs is 
> that both use Call-ID. I don't believe 3261 or any other RFC actually 
> uses the term "dialog" in relationship to registration. IMO it would be 
> best to refrain from even hinting that there is any such relationship. 

We're in agreement.

> I am inclined to think REGISTER should not even be mentioned 
> in this draft.

Silence on a topic is often interpreted as a tacit endorsement for
the implementor to fill in the blanks according to his or her wants,
often to the detriment of the protocol.  Explicitly warning people
not to create dialogs for REGISTER is a better strategy, IMHO.

I'll leave it to Robert on what to do; but my preference would be
to state point out in a forceful manner that protocol designers
should not even contemplate on doing this, nor should implementors
assume that REGISTER establishes a dialog usage that can be
shared.

Thanks.

- vijay
--

-- 
Vijay K. Gurbani  vkg <at> {lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vijay K. Gurbani | 2 Oct 2006 07:01
Picon
Favicon

Re: Question on draft-ietf-sipping-v6-transition

Livio Torrero wrote:
> I have a question on this draft concerning the behaviour of a dual-stack 
> UA. Consider the configuration shown here:  
> 
> UA A------Proxy A------------------Proxy B-------UA B.
> 
>  Assume that UA A, Proxy A and Proxy B are dual-stack, while UA B is 
> IPv4 only. Suppose that UA A wants to send an INVITE request to UA B: 
> since the next hop (Proxy A) is dual-stack, it sends the request through 
> IPv6; for this reason UA A has chosen its IPv6 address and has placed it 
> in the Contact header of the INVITE request. Since proxy B is dual-stack 
> too, proxy A forwards the request using IPv6. Then the request reaches 
> Proxy B that can reach UA B only using IPv4: this means that Proxy B 
> adds a record-route header to the INVITE and delivers it to UA B using 
> IPv4 (and proxy B will forward all the future SIP requests belonging to 
> the INVITE dialog). Is this the expected behaviour of this 
> infrastructure? Is it possible to assume that UA B (IPv4 only) will 
> place correctly the URI of UA A in the request-URI of the mid-dialog SIP 
> requests sent to UA A, even though such URI contains an IPv6 address (I 
> know it is supposed to be true for Record-routing entries)?

It should; as long as UA B is rfc3261-compliant, it can at the very
least parse IPv6 references and serialize them.  Since it is an
IPv4-only host, it won't be sending packets to destined to that
IPv6 reference; instead, it will have to depend on Proxy B to send
requests originated from it, so Proxy B would have to R-R (as you
already noted).

Also, note that the draft recommends that UA A put both IPv4 and
IPv6 addresses in the SDP to allow a media session to be established
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benny Prijono | 2 Oct 2006 13:17
Favicon

Re: WGLC review of draft-ietf-sipping-dialogusage-03

Vijay K. Gurbani wrote:
> Silence on a topic is often interpreted as a tacit endorsement for
> the implementor to fill in the blanks according to his or her wants,
> often to the detriment of the protocol.  Explicitly warning people
> not to create dialogs for REGISTER is a better strategy, IMHO.

I think partly the confusions come from RFC 3261 itself. While it says 
that the only dialog establishing method defined by 3261 is INVITE 
method, the sample REGISTER call flow (section 24.1, page 214) shows 
that the 200/OK response to REGISTER contains a To tag. As we know, 
the combination of From tag, To tag, and Call-ID defines a dialog, so 
looking at the sample call flow, people may mistakenly think that 
REGISTER session is a dialog. And I do see some people call REGISTER 
session a dialog.

I'm not suggesting that we should put explicit warning for REGISTER, 
but I'm not against it either. Although if we need to put specific 
text on REGISTER, then probably we'd better put it in broader context 
such as what methods establish a dialog.

-benny

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 1 comment |
headers
Samir Srivastava | 2 Oct 2006 21:12
Favicon

FW: WGLC review of draft-ietf-sipping-dialogusage-03

Hi Paul,

1) In line for REGISTER.
2) Draft doesn't mention anything on PUBLISH which is somewhat similar
to REGISTER. 

Thx
Samir

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> Sent: Sunday, October 01, 2006 7:29 PM
> To: Vijay K. Gurbani
> Cc: SIPPING LIST
> Subject: Re: [Sipping] WGLC review of
draft-ietf-sipping-dialogusage-03
> 
> I'd like to comment further on REGISTER.
> 
> As far as I can tell, the relationship between REGISTER and dialogs is
> that both use Call-ID. I don't believe 3261 or any other RFC actually
> uses the term "dialog" in relationship to registration.

3261 in section 10.2 Para 3 Ist sentence states the following.
"A REGISTER request does not establish a dialog."

Excuse my lack of knowledge of usage. When REGISTER doesn't establish a
dialog, then where is the question of dialog usage from REGISTER.
Parsing first two paras of Section 8.1.1.4 of 3261, makes it clear
Call-ID should not be shared.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Kyzivat | 3 Oct 2006 02:23
Picon
Favicon

Re: FW: WGLC review of draft-ietf-sipping-dialogusage-03

AFAIK, PUBLISH has no relationship with a dialog usage.
In that respect it is like OPTIONS and MESSAGE, that act the same inside 
and outside dialog.

	Paul

Samir Srivastava wrote:
> Hi Paul,
> 
> 1) In line for REGISTER.
> 2) Draft doesn't mention anything on PUBLISH which is somewhat similar
> to REGISTER. 
>  
> 
> Thx
> Samir
> 
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
>> Sent: Sunday, October 01, 2006 7:29 PM
>> To: Vijay K. Gurbani
>> Cc: SIPPING LIST
>> Subject: Re: [Sipping] WGLC review of
> draft-ietf-sipping-dialogusage-03
>> I'd like to comment further on REGISTER.
>>
>> As far as I can tell, the relationship between REGISTER and dialogs is
>> that both use Call-ID. I don't believe 3261 or any other RFC actually
>> uses the term "dialog" in relationship to registration.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Samir Srivastava | 3 Oct 2006 02:37
Favicon

RE: FW: WGLC review of draft-ietf-sipping-dialogusage-03

Then why we need to put REGISTER , as It doesn't create the dialog which
is categorically stated in 3261.

Thx
Samir

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> Sent: Monday, October 02, 2006 5:23 PM
> To: Srivastava, Samir (SC100:8826)
> Cc: Vijay K. Gurbani; SIPPING LIST
> Subject: Re: FW: [Sipping] WGLC review of
draft-ietf-sipping-dialogusage-
> 03
> 
> AFAIK, PUBLISH has no relationship with a dialog usage.
> In that respect it is like OPTIONS and MESSAGE, that act the same
inside
> and outside dialog.
> 
> 	Paul
> 
> Samir Srivastava wrote:
> > Hi Paul,
> >
> > 1) In line for REGISTER.
> > 2) Draft doesn't mention anything on PUBLISH which is somewhat
similar
> > to REGISTER.
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Kyzivat | 3 Oct 2006 03:21
Picon
Favicon

Re: FW: WGLC review of draft-ietf-sipping-dialogusage-03


Samir Srivastava wrote:
> Then why we need to put REGISTER , as It doesn't create the dialog which
> is categorically stated in 3261.

Well, I suggested not mentioning REGISTER. I also think PUBLISH need not 
be mentioned.

But PUBLISH is not analogous to REGISTER. REGISTER is treated in a very 
special way by 3261. It does call out the use of Call-ID, which has made 
Robert think it has some resemblance to a dialog.

	Paul

> Thx
> Samir
> 
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
>> Sent: Monday, October 02, 2006 5:23 PM
>> To: Srivastava, Samir (SC100:8826)
>> Cc: Vijay K. Gurbani; SIPPING LIST
>> Subject: Re: FW: [Sipping] WGLC review of
> draft-ietf-sipping-dialogusage-
>> 03
>>
>> AFAIK, PUBLISH has no relationship with a dialog usage.
>> In that respect it is like OPTIONS and MESSAGE, that act the same
> inside
(Continue reading)

Permalink | Reply | 0 comments |

Gmane