Hi，
> >
> > >
> > > >>>Is the flows below valid according to recent arguments?
> > > >>>
> > > >>> UAC UAS
> > > >>> |----invite(SDP)--->|
> > > >>> |<--- 183(SDP)------|
> > > >>> |-----prack(SDP)--->|
> > > >>> |<--- 200(SDP)------|
> > > >>>
> > > >>> flow 1
> > > >>>
> > > >>Assuming the 200 is the PRACK response, yes.
> > > >>>
> > > >>> UAC UAS
> > > >>> |----invite-------->|
> > > >>> |<--- 183-----------|
> > > >>> |-----prack(SDP)--->|
> > > >>> |<--- 200(SDP)------|
> > > >>>
> > > >>> flow 2
> > > >>>
> > > >>Not valid. If the INVITE does not contain SDP, a reliable answer must
> > > >>contain SDP. We are currently discussing whether the FIRST reliable
> > > >>response must contain SDP, or whether that rule can be related. But,
> > > >>that is a separate thread.
> > > >
> > > >Hmm. That flow is a consequence of changing that rule that I had not
> > > previously considered.
> > > >
> > > >Allowing flow 2 would cause all sorts of trouble. If the restriction on
> > > offer in first reliable provisional is to be
> > > >relaxed it must be sure to state that the first offer must then be in
> > > *some* reliable provisional, and until that is sent
> > > >there can be no offer sent another way (PRACK or UPDATE).
> > > >
> > > >Just opening that question is enough to make me more concerned about
> > > relaxing the constraint.
> > >
> > > I am not proposing to allow flow 2, and I don't think relaxing the rule
> > > would allow it either. The rule would say that if the INVITE does not
> > > contain an SDP offer the SDP offer must be carried in a reliable
> > > response. The PRACK can only contain an SDP offer if the UAC has receied
> > > an SDP answer.
> >
> > Does it means,the first flow is allowed?
>
> Yes.
> > I think, the restriction the first reliable response must contain SDP if
> > the INVITE without SDP
> > should restrict the called user.
>
> That's the way it is now.
Sure, I means, the first reliable response from the called user must contain
NORMAL SESSION SDP in order to communication,but AS(application server)
shouldn't be restricted by this rule as AS may only concern about early-session
for pronunciation. Or, the AS is also restricted if early-session plays the same
role as normal session.
Regards,
Eric
>
> > It seems there is a exception about H.323, but i know nothing about the
> > case at this moment, does
>
> There is currently no such exception. There is some discussion underway
> regarding possibly making one. H.323 behavior is one justification.
>
> > the unreliable response or delaying to send the first reliable response
> > solve the H.323 case?
>
> delaying does.
>
> Paul
>
> > Regards,
> > Eric
> >
> >
> > --------------------------------------------------------
> > 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.
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
