Hi，
>
>
> wang.libo@xxxxxxxxxx wrote:
>
> > > > > >>>Is the flows below valid according to recent arguments?
> > > > > >>>
> > > > > >>> UAC UAS
> > > > > >>> |----invite(SDP)--->|
> > > > > >>> |<--- 183(SDP)------|
> > > > > >>> |-----prack(SDP)--->|
> > > > > >>> |<--- 200(SDP)------|
> > > > > >>>
> > > > > >>> flow 1
>
> > > > 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.
>
> The AS is an artifact of IMS, it has no role in any of the ietf
> standards. It has been expected that components playing various roles
> such as this are bound by normal distinctions between UAC, UAS, Proxy, etc.
>
> IMO it isn't a good idea to introduce a new kind of UA (or proxy) that
> is bound by different rules.
>
I think we don't need to introduce a new kind of (UA).
And obeying the existed rules, AS can work well at almost all the use-cases.
As UA and AS both exist in a basic call,we just need to make few modifications if needed.
> You might consider the "early-session" mechanism specified by RFC 3959.
> But I have never heard of it being implemented, so it may not be useful
> to you.
>
Yes.
Early-session has already been implemented in own system. And I think it do
have some advantage, as both early-session and session can be carried by a message,
also,early-session solves media clip.
(P-early-media with different TO-tag is another way.)
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.
_______________________________________________ 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
