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

From: "Christian Jansson" <[email-masked]>
Date: Mon, 8 Nov 2004 15:45:58 +0100

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: [email-masked]
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 8 Nov 2004 10:30:21 -0500

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:

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