Re: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? Second attempt.

[Rohan Mahy <[e-mail]>]

On Nov 8, 2004, at 11:33, Christian Jansson wrote:

> I saw that the draft had made it to RFC so in some way I am too late, 
> but I still do not see the advantages with Join.

At this point, we have a standard track document that was reviewed by 
the WG, expresses a consensus approach, technically works, and has a 
handful of implementations.  I don't think there is much value 
rehashing this issue.

> "The simplest example is that a Replaces header sent to a locally 
> mixed conference might match multiple dialogs"
> Is that an advantage or disadvantage of Join vs the model I proposed?
>
> "It is then impossible to replace a single (specific) dialog"
> But wouldn't that be possible with the proposal I wrote also? I think 
> so. Do you have any reference to mailing-list discussions where you 
> realized that what was in RFC3261 was not enough?
>
> I thought it would be good to reuse the elements that are in 3261. In 
> a way dialogs could be seen to be coupled to a call-id in a heretical 
> view.
>
> In the case below UA:A has a call containing 2 dialogs with dialog-ids 
> (1234:A1:BB) and (1234:A2:CC). If one would like to use Replaces to 
> replace one of the dialogs then simply target one of them using the 
> dialog id. To me Join seems to invent the wheel again.

You can't use the fact that the call-id is the same to assume that two 
calls are part of the same conversation.  For example, when forking an 
INVITE for video or text, it is quite reasonable to get multiple 200s 
(and multiple independent sessions) which stay up.  These are most 
likely not part of the same conversation.

thanks,
-rohan


>      UA:A
>
>     Call-id: 1234
>      |          |
>  local-tag=A1  local-tag=A2
>  remote-tag=BB remote-tag=CC
>
> In this model it is very easy to see that the two dialogs are 
> connected, as they both share the call-id part of their dialog-id. I 
> think that is a very attractive feature.
>
> Now if we use Join instead do the same thing, we would get some state 
> above this (conference?) that relates one dialog with another dialog 
> with a completely different set of identifiers. It also makes the 
> call-id identifier more or less useless except for the case when 
> forking gives back multiple answers, which probably won't happen under 
> normal operation. Does this state above dialogs and call-ids have a 
> name defined anywhere?
>
>
> / Christian Jansson
>
>
> ________________________________________
> From: Rohan Mahy [mailto:[e-mail]]
> Sent: Monday, November 08, 2004 4:30 PM
> To: Christian Jansson
> Cc: Rohan Mahy; [e-mail]
> Subject: Re: [Sip] Join header (draft-ietf-sip-join-03.txt) 
> unnecessary? Second attempt.
>
> Hi,
>
> Sorry for the delayed response.
>
> Based on our experiences with Replaces, Dan Petrie, Alan Johnston, 
> Robert Sparks, myself and other members of the working group where 
> able to point out significant problems with reusing dialog identifiers 
> for multiple dialogs. The simplest example is that a Replaces header 
> sent to a locally mixed conference might match multiple dialogs. It is 
> then impossible to replace a single (specific) dialog. Also Join 
> allows a user agent to redirect a Join request to a conference in a 
> much more natural way. Hope this helps. In any case, Join is now 
> RFC3911.
>
> thanks,
> -rohan
>
> On Nov 8, 2004, at 9:45, Christian Jansson wrote:
>
> I got no answers on this question last time so I try again.
>
>  
>
> Is the approach described below so naive that no one even has the 
> energy point out its weaknesses? Maybe it has already been discussed 
> and deemed inadequate?
>
>  
>
> / Christian
>
>  
>
>  
>
> From: Christian Jansson
> Sent: den 21 oktober 2004 16:05
> To: [e-mail]
> Subject: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? 
> [html]
>
>  
>
> Why do we need a Join header to be able to indicate that we want to 
> join an ongoing session? Wouldn't it be enough to, for the party that 
> wants to join, actually use the call-id for the session when sending 
> the join-INVITE? Suppose A and B are in a session with the dialog 
> identified by call-id=12345;tag=A;tag=B. If C now wants to join the 
> session he sends an INVITE to A or B with call-id=12345, from-tag=C, 
> and an empty to-tag. Wouldn't it make more sense that the 2 dialog-ids 
> had some parts in common, that is the call-id, and something that 
> distinguished them, that is the to and from tags? It would be much 
> easier to find the session related messages as they would share the 
> same call-id.
>
>  
>
> Have I missed some essential part of the Join header, or are we just 
> adding something that we could already express easily with what we 
> already have?
>
>  
>
>  
>
> / Christian Jansson, Hotsip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip