Hi Pavan ,
I guess you need to go through RFC3312 once for getting clarity about
precondition once .
Coming to ur questions :
1. Precondition is just a feature for which support can be mentioned in
Supported and Require header .
And if support is there , QOS parameters must be set in SDP .There is no
other way to send QOS parameters.
2. conf parameter is not mandatory and its actually requirement driven .
If UAS wants to confirm QOS status of UAC before accepting call , then
it must add a:conf in sdp of 183 response.
Thanks & regards
Ankur Bansal
On Fri, Sep 27, 2013 at 11:54 AM, Pavan Kumar
<[email protected]>wrote:
> Ankur,
>
> can we send only "precondition" in response without SDP.
>
> 180(Pre-condition only a: parameters) (or) it should be with SDP
>
> 2) is it mandatory to have conf? it is optional right?
>
> ------------------------------
> *From:* ankur bansal <[email protected]>
> *To:* Aditya Kumar <[email protected]>
> *Cc:* "[email protected]" <
> [email protected]>
> *Sent:* Thursday, September 26, 2013 7:54 PM
> *Subject:* Re: [Sip-implementors] pre condition in conf tag
>
> Hi Aditya ,
>
> This media attribute line usually comes from UAS in 183 response in case of
> preconditions (QOS) .
> Sending this ,UAS wants confirmation from UAC that whenever resource
> reservation (dedicated bearer) done
> please send Update to me ,then I will pass Incoming call indication to user
> .
>
>
> -----------------INVITE
> sdp(a=inactive)-------->Incoming call indication not passed to user
> Resource reservation starts<---------------183
> sdp(a=inactive)-------------- Resource reservation starts
> ----------------PRACK
> ------------------->
> <----------------200 ok
> ------------------- -
>
> Resource reservation
> done Resource
> reservation done
>
> --------------UPDATE
> sdp(a=sendrecv) ---------> Pass incoming call indication to user
> <----------------200 ok
> sdp(a=sendrecv) ---------
> <----------------180
> Ringing---------------
>
> <----------------200ok(invite)--------------
>
> ------------------ACK------------------------->
>
> This is very basic scenario ,and there are multiple other scenarios
> depending upon :
> 1.If any party already have resource reservation present
> 2.If UAS don't understand preconditions
> 3.If delay happens in resource reservation then UAC will have delay in
> sending Update sdp and UAS will have
> delay in sending 180 ringing .
>
> The scenario where UAS don't need Confirmation from UAC regarding resource
> reservation :
> 1 .When UAC sends INVITE with qos parameters saying UAC already have
> resource reservation and UAC wants
> UAS to reserve resources before establishing call .
>
> Resource reservation done
> -----------------INVITE
> sdp(a=sendrecv)-------->Incoming call indication not passed to user
> <---------------183
> sdp(a=sendrecv)-------------- Resource reservation starts
> ----------------PRACK
> ------------------->
> <----------------200 ok
> ------------------- -
>
>
> Resource
> reservation done then Pass incoming
>
> call indication to user
>
> <----------------180
> Ringing---------------
>
> <----------------200ok(invite)--------------
>
> ------------------ACK------------------------->
> 2.If UAS don't support preconditions ...In this case UAS directly send 180
> ringing and then 200 ok sdp.
>
> Thanks & regards
> Ankur Bansal
>
>
> On Thu, Sep 26, 2013 at 10:44 PM, Aditya Kumar <[email protected]
> >wrote:
>
> > Hi,
> >
> > Can any one please explain me about
> > a=conf:qos remote sendrecv
> > this header in detail. I did not understand that.
> >
> > what is the confirmation for? is it only Target can sent it?
> >
> > why do we need conformation when in the
> > a=curr:qos remote none
> > The target can tell its current state and change if needed in
> > a=des:qos mandatory remote sendrecv
> >
> > -Adi
> >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
