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

["Christian Jansson" <[e-mail]>]

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.

"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.

     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