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)
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) ????
Thanks,
Nataraju A B
On Sat, Mar 17, 2012 at 11:48 PM, Paul Kyzivat <[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]
> 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
