<snip>
> >
> > UA_A sends an INVITE, with SDP (offer 1).
> >
> > UA_B sends back the first 18x provisional response, WITH
> SDP (answer 1).
> >
> > UA_A sends the first PRACK, WITHOUT SDP.
> >
> > UA_B sends back the second 18x provisional response, WITHOUT SDP.
> >
> > UA_A sends the second PRACK, WITH SDP (offer 2).
>
> This is illegal. According to 100rel:
>
> If the UAC receives a reliable provisional response with an offer
> (this would occur if the UAC sent an INVITE without an offer, in
> which case the first reliable provisional response will contain the
> offer), it MUST generate an answer in the PRACK. If the
> UAC receives
> a reliable provisional response with an answer, it MAY generate an
> additional offer in the PRACK. If the UAS receives a PRACK with an
> offer, it MUST place the answer in the 2xx to the PRACK.
>
>
> Generating additional offers in the PRACK is contingent on
> receiving an
> answer in the 1xx.
The text could be clearer. The statement 'If the UAS receives a PRACK with an offer ...' is not qualified to say that this refers only to the PRACK to a 1xx containing an answer - it could be read as applying to any PRACK, although it's appearence in this particular paragraph ought to give you a hint.
This is unless there is another statement somewhere else along the lines of 'The UAC MUST NOT include an offer in a PRACK except when the PRACK acknowledges a 1xx containing an answer.'
Perhaps even a table showing all the valid combinations for offers/answers in non-UPDATES would be useful - I think there are only four cases - someone pls correct me if I'm wrong:
Each column to be read as an allowable call flow. No additional messages are allowed in the call flow except between the 200 OK of the PRACK and the 200 OK of the INVITE.
+-------------------------------+
|Message | 1 | 2 | 3 | 4 |
+---------------+---+---+---+---+
|>INVITE | O | O | O | |
+---------------+---+---+---+---+
|<Rel 1xx | | A | A | O |
+---------------+---+---+---+---+
|>PRACK | | | O | A |
+---------------+---+---+---+---+
|<200 OK (PRACK)| | | A | |
+---------------+---+---+---+---+
|<200 OK (INV) | A | | | |
+---------------+---+---+---+---+
> The result is that there will only ever be one generating of
> an offer in
> PRACK, since only the first reliable provisional response can have an
> answer.
>
> -Jonathan R.
>
>
> --
> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> jdrosen@dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PH: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>