Subject: RE: [Sipping]Re: I-DACTION:draft-loreto-sipping-dialog-correlation-00.txt

From: "Ilan Avner" <[email-masked]>
Date: Wed, 29 Mar 2006 23:42:33 +0200

Hi Gonzalo,
I have a question regarding the same-session new suggested header.
This new header resembles the Join and the Replaces and Target-Dialog
headers in many ways.
First the syntax of this new header is almost similar.
The rules for matching existing dialogs to this new header are almost
the same (apart from matching early dialogs).
Now lets assume someone in the future will define a new draft that uses
these same behavior (try to relate a new invite to an existing dialog),
should he duplicate all the definitions defined in these older drafts?
Should he define a new header with the exact syntax as the previous
headers defined before?
Isn't there a place for defining a general way or header that is used
for relating a new incoming Invite to an existing dialog?
What I am suggesting is some kind of a general header such as:
Related-Dialog:
call-id=[email-masked];local-tag=kkaz;remote-tag=6544;reason=same-sess
ion.

Where the reason parameter indicates the purpose of relating this new
Invite to an existing dialog.

If we do it this way, future drafts will be able to reuse this new
behavior for other needs without duplicating the existing logic
regarding matching existing dialogs.
All they have to do is define a new reason parameter that will be used
by the same new header.

Regards

Ilan.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, March 24, 2006 19:22
To: Even, Roni
Cc: sipping; Gonzalo Camarillo
Subject: Re: [Sipping]Re:
I-DACTION:draft-loreto-sipping-dialog-correlation-00.txt

Even, Roni wrote:

>Hi Gonzalo,
>The example in the email thread 
>"For example, I walk into a meeting room while talking on my audio-only
mobile terminal and I want to add video using the fixed camera and large
screen in the meeting room." 
>Is a good example. I am aware that using a phone for audio and a
separate appliance or web camera for video is available in real
products. The correlation is done in a central entity and you cannot
easily achieve the scenario you describe in the above example being of
ad-hoc relationship. The need to the correlation in this case is
important, for example, for lip-synch or in multipoint for voice
activated video switch.

I think you're right. It sounds like we need "a light-weight
message-oriented coordination protocol for group communication between
application components." To support this specific use case in a
transparent fashion, it sounds like it need to provide "automatic
location of communication peers."

Text in quotes is not my own. I attribute it to the abstract of
http://www.ietf.org/rfc/rfc3259.txt

My point being: we solved this problem already. We're hearing from
multiple people that we need multi-device coordination. Let's leverage
the wheel that we've already invented instead of starting from scratch.

/a

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

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