On 3/17/12 3:02 PM, Nataraju A.B wrote:
> Paul, Thanks for the clarification, I got the point...
>
> According to the Pattern 3 of rfc6337, following scenario is a valid.
>
> UAC UAS
> INV (SDP-A)----->
> *<------- rel-1xx (no SDP)*
> <------- rel-1xx ( SDP-B )
> <------- rel-1xx (no SDP)
> <------- 2xx ( no SDP)
Yes.
> My next question is with respect to content in RFC3261.
>
> Why the first the answer must be in *one of the reliable responses*
> (early media scenario). whereas in the delayed media scenario the offer
> *must *be in *first *reliable response.....
>
> was this requirement derived from PSTN / ISDN / .... ????
>
> Why not both of them to be *MUST* requirements / *one of* requirements
> (just out of curiosity) ????
I have not been able to discover an answer to this. It may have been a
mistake. This was discussed many years ago. Nobody could come up with a
strong argument for this restriction. We also discussed removing it. But
concluded that doing so would be a backward incompatibility, and making
it support of a change optional would be worse than leaving it as it is.
Thanks,
Paul
> Thanks,
> Nataraju A B
>
> On Sat, Mar 17, 2012 at 11:48 PM, Paul Kyzivat <[email protected]
> <mailto:[email protected]>> wrote:
>
> Inline
>
> On 3/17/12 1:44 PM, Nataraju A.B wrote:
> > Hi All,
> >
> > Following is the excerpt from the RFCs 3261 and 6337, with respect to
> > Answer being carried in Reliable-1xx and 2xx-INV
> >
> > <3261>
> >
> > o If the initial offer is in an INVITE, the answer *MUST
> *be in a
>
> Note the last word above is "a", not "the first".
>
> > reliable non-failure message from UAS back to UAC which is
> > correlated to that INVITE. For this specification, that is
> > only the final 2xx response to that INVITE. That same
> exact
> > answer MAY also be placed in any provisional responses sent
> > prior to the answer. The UAC MUST treat the first session
> > description it receives as the answer, and MUST ignore any
> > session descriptions in subsequent responses to the initial
> > INVITE.
> >
> > </3261>
> >
> > <6337>
> >
> > In Pattern 3, the first reliable provisional response *may or
> may not*
> > have an answer. When a reliable provisional response contains a
> > session description, and is the first to do so, then that session
> > description is the answer to the offer in the INVITE request.
> The
> > answer cannot be updated, and a new offer cannot be sent in a
> > subsequent reliable response for the same INVITE transaction.
> >
> > </6337>
> >
> > Looks like rfc6337 is little bit deviating from 3261's intention.
> > rfc6337 - may or may not requirement for carrying answer in
> reliable 1xx
> > rfc3261 - MUST requirement for carrying answer in 2xx/reliable
> > non-failure response
> >
> > Am I missing something here ????
>
> Yes.
>
> When the offer is in the invite, the answer must be in a reliable
> response, but it need not be the first reliable response. 3261 says this
> and 6337 restates it in a way that is hopefully clearer.
>
> I think you are mixing this up with the prior paragraph in 3261:
>
> o The initial offer MUST be in either an INVITE or, if not
> there,
> in the first reliable non-failure message from the UAS back to
> the UAC. In this specification, that is the final 2xx
> response.
>
> Namely, its when there is no offer in the INVITE that it must be in the
> *first* reliable response. This is covered by patterns 2 and 4 of 6337.
>
> Thanks,
> Paul
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
>
> --
> Thanks,
> Nataraju A.B.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
