Subject: [Sipping] Comments on conferencing models

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 18 Oct 2002 15:53:28 +0300

Hi,

Section 3.1 of the conferencing models draft:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-models-01.txt

still refers to appendix B of RFC 2543. It needs to be updated to say
that now there MUST always be an answer to an offer with multicast
streams.

Section 7 assumes that an end-system will return the same address/port
in the response to a previous INVITE/re-INVITE and in the response to
the current re-INVITE. That 3pcc flow (figure 7) has to be worked out
again without that assumption. 

In all the 200 OK answers: (8), (11), (14), and (17), the answerer might
have changed port and address of any stream. If this happens, the
conference server will have to send an empty re-INVITE (19), (20) and so
on... to all the participants at the same time (in parallel), and wait
for all the 200 OK responses with offers before ACKing any of them. Once
the conferece server has all the information (all the offers), it will
send answers in ACKs to all the members of the conference.

This is a slightly more complex flow, but it works regardless of the
behaviour of the end-systems (which we can make a SHOULD, but not a
MUST).

Regards,

Gonzalo
_______________________________________________
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