Re: [sipcore] 答复: Re: Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft

["Christer Holmberg" <[e-mail]>]

Hi,

I think you are asking for problems if you start combining preconditions and non-preconditions in a re-INVITE. 

It is already difficult enough to be sure on when the new media parameters will be taken in use, and when the old ones cannot be used anymore, so if different parameters are to be taken into use at different times I think it will create a mess...

So, why not do the audio change and the video change in separate transactions?

But, I need to do some more thinking before answering your question. In principle I guess it would be good to keep each media stream as separate as possible, but the way SIP, SDP and the media descriptions are boundled together there may be some limitations.

We also need to keep in mind that the precondition modification can fail, and what happens to the non-precondition change in that case.

Regards,

Christer


 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: 20. elokuuta 2009 22:00
> To: [e-mail]
> Cc: Christer Holmberg; Gonzalo Camarillo; SIPCORE; 
> [e-mail]
> Subject: Re: 答复: Re: Suspending and Resuming modification of 
> session or stream? //New revision of the re-INVITE handling draft
> 
> 
> 
> [e-mail] wrote:
> > 
> > Hi Paul,
> > 
> > As you can see that i am arguing in favor of suspension being 
> > per-stream :).
> > It is a clerical error. I prefer "suspending is effective 
> for streams 
> > with precondition", the 2st one.
> > 
> > But RFC 3312 & 4032 has such description:
> > While session establishment is suspended(for QoS type 
> precondition), 
> > user agents SHOULD not send any data over *any media 
> stream*.  In the 
> > case of RTP, neither RTP nor RTCP packets are sent.
> > 
> > So, do we need correction for this?
> 
> I haven't thought about it a lot, but my immediate reaction 
> is *yes*, this doesn't seem right. I would like to hear what 
> Gonzalo thinks.
> 
> In the writing of 4032, I think the focus here was on 
> narrowing the scope of this limitation, so that it applied 
> only to QoS and not other precondition types. I don't think 
> ay consideration was given to
> 
> 	Thanks,
> 	Paul
> 
> > Thanks.
> > 
> > Gao
> > 
> > ===================================
> > Zip    : 210012
> > Tel    : 87211
> > Tel2   :([phone]
> > e_mail : [e-mail]
> > ===================================
> > 
> > 
> > *Paul Kyzivat <[e-mail]>*
> > 
> > 2009-08-20 21:01
> > 
> > 	
> > 收件人
> > 	[e-mail]
> > 抄送
> > 	SIPCORE <[e-mail]>, Gonzalo Camarillo 
> > <[e-mail]>, Christer Holmberg 
> > <[e-mail]>, [e-mail]
> > 主题
> > 	Re: Suspending and Resuming modification of session or 
> stream?   //New 
> > revision of the re-INVITE handling draft
> > 
> > 
> > 	
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > [e-mail] wrote:
> >  >
> >  > Considering a use case, A and B has a audio only session. Then A 
> > send a  > Re-INVITE for adding vedio stream( with precondition) and 
> > changing codec  > or address for audio stream( without preconditon).
> >  >
> >  > If suspending is effective for whole session, then 
> streams without  
> > > precondition should use old parameters while in suspending state.
> >  > For the use case, A and B should not use new codec or 
> address for 
> > audio  > before vedio's preconditon is met.
> >  >
> >  > If suspending is effective for streams with 
> precondition, the then  
> > > streams without preconditio can use new parameters after 
> first O/A  
> > > during the Re-INVITE.
> >  > For the use case, A and B can use new codec or address for audio 
> > before  > vedio's preconditon is met.
> >  >
> >  >
> >  > I prefer the first one, as;
> > 
> > You mean that you prefer suspension being for the whole 
> session (*all* 
> > streams)???
> > 
> >  > 1. To delay using of new parameters for stream without 
> precondition 
> > may  > arose media clip problem.
> >  > 2. Behavior of streams without precondition should be 
> independent 
> > of  > existence of other streams( with precondition).
> > 
> > It seems you are arguing in favor of suspension being per-stream.
> > 
> > IMO the suspension behavior is defined on a per-stream basis and so 
> > needs to be implemented that way.
> > 
> > Another reason for this is that it is possible the various 
> streams are 
> > not controlled by the same entity, so that coordination of 
> when they 
> > take effect could be problematic.
> > 
> > If someone wants the changes to multiple streams to take effect 
> > together they are free to put preconditions on them all and 
> > synchronize the resolution of those preconditions.
> > 
> >                 Thanks,
> >                 Paul
> > 
> >  > ===================================
> >  > Zip    : 210012
> >  > Tel    : 87211
> >  > Tel2   :([phone]
> >  > e_mail : [e-mail]
> >  > ===================================
> >  >
> >  > --------------------------------------------------------
> >  > ZTE Information Security Notice: The information 
> contained in this 
> > mail is solely property of the sender's organization. This mail 
> > communication is confidential. Recipients named above are 
> obligated to 
> > maintain secrecy and are not permitted to disclose the contents of 
> > this communication to others.
> >  > This email and any files transmitted with it are 
> confidential and 
> > intended solely for the use of the individual or entity to 
> whom they 
> > are addressed. If you have received this email in error 
> please notify 
> > the originator of the message. Any views expressed in this 
> message are 
> > those of the individual sender.
> >  > This message has been scanned for viruses and Spam by 
> ZTE Anti-Spam 
> > system.
> >  >
> > 
> > 
> > 
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained 
> in this mail is solely property of the sender's organization. 
> This mail communication is confidential. Recipients named 
> above are obligated to maintain secrecy and are not permitted 
> to disclose the contents of this communication to others.
> > This email and any files transmitted with it are 
> confidential and intended solely for the use of the 
> individual or entity to whom they are addressed. If you have 
> received this email in error please notify the originator of 
> the message. Any views expressed in this message are those of 
> the individual sender.
> > This message has been scanned for viruses and Spam by ZTE 
> Anti-Spam system.
>