Subject: Re: [MMUSIC] I-D Action:draft-boulton-mmusic-sdp-control-package-attribute-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Feb 2008 10:42:57 -0500

I have one comment about this draft. (Caveat: while I read this draft I 
haven't read the framework yet.)

Section 3 states:

    It should be noted that the 'ctrl-package' attribute does not have
    any context outside the initial offer/answer exchange.  It is simply
    to provide two Control Framework clients an opportunity to convey
    supported Control Packages.  The SIP Control Framework has its own
    dynamic negotiation mechanism that is used to negotiate session level
    supported Control Packages.  Allowing such additional semantics
    during an active Control Framework session would result in confusing
    and conflicting operation.  For this reason, after the initial offer/
    answer exchange has taken place, the 'ctrl-package' attribute (and
    changes to it) has no impact on the Control Framework session and
    should be ignored.

How does this play out when 3pcc is used? Specifically if 3pcc is used 
to accomplish a transfer. In that case one participant may think it is 
just getting a subsequent o/a in an existing session, but the session is 
being transferred to a different participant that thinks this is a new 
session. (This may or may not be perceived as a change of media streams 
depending on whether they are e2e or bridged.)

	Thanks,
	Paul

_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 7 Feb 2008 16:52:18 -0000

Section 3 states:

    dynamic negotiation mechanism that is used to negotiate session
level
    and conflicting operation.  For this reason, after the initial
offer/

[Chris Boulton] Yes Paul - this is a very good example.  Do you think
the solution would be better if it was linked to the 'connection'
attribute of COMEDIA which is used by the Control Framework?  So in the
'existing' case it would be ignored but in the 'new' case the value
would be useful.  So when your 3PCC controller initiates the 'transfer'
to the existing dialog it would have a 'new' value.

Chris.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Feb 2008 16:56:34 -0500

Chris Boulton wrote:
> [Chris Boulton] Yes Paul - this is a very good example. 

For a long time now I have found 3pcc to be a wonderful source of 
problematic use cases for all sorts of o/a enhancements. (To paraphrase 
somebody: "It ain't done 'till 3pcc works.")

> Do you think

I fought long against the existing/new solution, because it is so 
different from the way o/a normally works. I eventually gave in because 
we couldn't find anything else that worked. But I wouldn't recommend it 
as a solution unless there is nothing better.

IMO it is far better to have an idempotent solution, where you 
constantly state what your current state is, and it just causes the 
right thing to happen in those cases where something *needs* to happen.

I don't know your overall solution, so I can't comment on whether that 
is possible for you or not. But my recommendation is for you to see if 
there is. If you can't find something better then at least the 
existing/new paradigm is a pattern that can be reused.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 Feb 2008 12:46:49 +0100

Hi,

I don't like ideas of having attributs "which have no meaning". In that
case, they shouldn't be sent in the first place.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 7. helmikuuta 2008 17:43
> To: IETF MMUSIC WG
> Subject: Re: [MMUSIC] 
> I-DAction:draft-boulton-mmusic-sdp-control-package-attribute-01.txt
> 
> I have one comment about this draft. (Caveat: while I read 
> this draft I haven't read the framework yet.)
> 
> Section 3 states:
> 
> How does this play out when 3pcc is used? Specifically if 
> 3pcc is used to accomplish a transfer. In that case one 
> participant may think it is just getting a subsequent o/a in 
> an existing session, but the session is being transferred to 
> a different participant that thinks this is a new session. 
> (This may or may not be perceived as a change of media 
> streams depending on whether they are e2e or bridged.)
> 
> 	Thanks,
> 	Paul
> 
>

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 8 Feb 2008 16:06:44 -0000

I don't know your overall solution, so I can't comment on whether that 
is possible for you or not.

 But my recommendation is for you to see if 
there is. If you can't find something better then at least the 
existing/new paradigm is a pattern that can be reused.

[Chris Boulton]OK - so maybe if I tweak what I said early - is it more
palatable? (and I think takes onboard Christer's comments - which I
agree with).  The 'control-package' attribute would only be included IF
a new connection is established (based on 'New').  That way, in the 3PCC
case it doesn't make any assumptions on it being an initial request and
would work.

Chris.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Feb 2008 11:56:36 -0500

at end...

> case it doesn't make any assumptions on it being an initial request and

I don't understand all you are doing, so I am just going to ask dumb 
questions that may elicit the issues. Consider the following scenario.

- UA A is connected to UA C with a B2BUA B (signaling only) in the middle.

- A had used the control-package attribute during the initial setup of 
that call. It was relayed by B to C. You have a media control channel 
established between A and C.

- B decides to transfer the call to D.

- To do so, B sends an offerless reinvite to C. It intends to use the
   offer in the response to that as an offer in an invite to D.

In that case, What should C include in the offer it puts in the response 
to the reinvite? Doesn't it need the control-package  attribute for the 
benefit of D, for whom this will be a new call? If so, how do you 
arrange for that? If not, why isn't it needed?

It would be best here if B doesn't have to know anything about this 
extension, or take any special actions as a result.

	Thanks,
	Paul

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 11 Feb 2008 13:52:16 -0000

[Chris Boulton] Paul - one thing that confuses me.  In the case of
COMEDIA, what would you expect 'normal' operation to be in your example
in relation to the value of the 'connection' attribute from C in
response to your offer-less INVITE?

Chris.