Subject: RE: [Sip] Discussion: Mixing unicast/multicast in offer/answer

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 23 Aug 2001 06:46:34 -0700

No objection to this resolution.

However I though I would point out that the Offer/Counter-offer/Answer SDP
model suggested in the "Weakness in SIP offer/answer model" thread may be
helpful in solving this problem without a re-invite. 

It falls into the general problem category of:

Caller proposes some media configuration A which is disagreeable to callee,
therefore, callee counter-proposes media configuration B back to caller.
Additionally, the solution must avoid the situation where the caller
believes the call is successfully answered but in fact the caller lacks the
capability to support media configuration B.

[Please reply to original thread to discuss solution details.]

Robert.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 11:32 PM
> To: [email-masked]'
> Subject: [Sip] Open Issue #20: Mixing unicast/multicast in 
> offer/answer
> 
> 
> Issue:
> 
> Appendix B is silent on whether its allowed to send an SDP 
> offer with a c
> line thats unicast, and answer with multicast. Same with the 
> inverse: can
> you answer  a multicast offer with unicast?
> 
> Points for discussion:
> 
> In general, it is my view that the answer SDP should always 
> be something
> that the offerer is guaranteed to be able to use. That is a 
> consequence of
> the two way offer/answer handshake. If an offer is unicast, answering
> multicast seems a bad thing, since you don't know whether the 
> offerer can do
> unicast. The argument is a bit weaker for the inverse case, 
> but there could
> be cases where one is being invited to an mbone session that 
> is multicast,
> where responding unicast makes little sense.
> 
> Furthermore, the semantics of mixed unicast/multicast in 
> offer answer aren't
> entirely clear. 
> 
> Proposal:
> 
> If the offer is unicast, so must be the answer. If the offer 
> is multicast,
> the answer should mirror that address (i.e., use the same 
> multicast group).
> If you want a particular stream to change from unicast to multicast,
> re-invite to update it.
> 
> There was consensus on this proposal at IETF 51. Any list objections?
> 
> Thanks,
> Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>  
> 
> _______________________________________________
> Sip mailing list  http://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
> 

_______________________________________________
Sip mailing list  http://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