>In a previous thread (No SDP in 200 reply to INVITE), Nataraju A.B. wrote:
>
>'If the 1xx responses were sent reliably then it's optional to carry the SDP
>in 200 responses.'
>
>I can't for the life of me find in the RFCs where this is stated. Please
>could you enlighten me.
Yes, it is not mentioned clearly in the RFC 3261,RFC 3262,RFC 3264. This has been discussed many times in the Sip-implementors
Following draft solve this problem by clearly stating the six patterns for exchanging an offer and an answer
http://www.ietf.org/internet-drafts/draft-sawada-sipping-sip-offeranswer-00.txt
Offer Answer RFC Ini Est Early
-------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 O O X
2. 2xx INVITE Resp. ACK Req. RFC 3261 O O X
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 O O X
4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 O O X
5. PRACK Req. 200 PRACK Resp. RFC 3262 X O O
6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 X O O
UAC UAS
| F1 INVITE (no SDP) |
|-------------------->|
| F2 1xx (SDP) | <- SDP may be included but it is not the
|<--------------------| offer. UAC may act as if it receives
| | the offer.
| F3 1xx-rel (SDP) | <- The first 1xx-rel must contain an SDP
|<--------------------| as the offer.
| F4 PRACK (SDP) | <- An PRACK request to the first 1xx-rel
|-------------------->| must contain an SDP as the answer.
| F5 2xx PRA (no SDP) | -
|<--------------------| |
| | |
| F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not
|<--------------------| | contain an SDP.
| F7 PRACK | |
|-------------------->| | UAC may send a new offer in a PRACK or
| F8 2xx PRA | | an UPDATE request after F4.
|<--------------------| v
| |
| F9 2xx INV (no SDP) | <- The final response should not
|<--------------------| contain an SDP.
| F10 ACK |
|-------------------->|
The final response should not contain an SDP.
UAC UAS
| F1 INVITE (SDP) | <- The offer in offer/answer model
|-------------------->|
| F2 1xx (SDP) | <- The SDP is not an official answer but
|<--------------------| UAC act as if it receives the answer.
| | ^
| F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer
|<--------------------| | SDP.
| F4 PRACK (no SDP) | |
|-------------------->| | UAC must not send a new offer.
| F5 2xx PRA (no SDP) | |
|<--------------------| v
| |
| F6 1xx-rel (SDP) | <- The answer in offer/ answer model
|<--------------------| -
| F7 PRACK | | After F6, UAC can send new offer in a
|-------------------->| | PRACK or UPDATE request.
| F8 2xx PRA | | UAS can send a new offer in an UPDATE
|<--------------------| v request.
| |
| F9 1xx-rel | <- SDP should not be included in the
|<--------------------| subsequent 1xx-rel once offer/answer
| F10 PRACK | has been completed.
|-------------------->|
| F11 2xx PRA |
|<--------------------|
| |
| F12 2xx INV | <- SDP should not be included in the final
|<--------------------| response once offer/answer has been
| F13 ACK | completed.
|-------------------->|
SDP should not be included in the final response once offer/answer has been completed.
In theory, any SIP message can include session description in its
body. But not all the session description in a SIP message is an
offer or an answer. Only the session description that conforms to the
rules described in the standard track RFCs can be interpreted as an
offer or an answer. The rules how to handle offer/answer model are
currently defined in several RFCs. Unless defined in an RFC
explicitly as an offer or an answer, except ones in non-reliable
provisional response to INVITE request, a session description should
not be included in SIP messages to avoid confusions.
Regards,
Thangarajan.
FlextronicsSoftware
Worlds largest SIP stack vendor
hema ramesh <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 02/17/2006 06:47 PM |
|
RFC 3261 Section 13.2.1 also says
"Concretely, the above rules specify two exchanges for UAs compliant to
this specification alone - the offer is in the INVITE, and the answer in
the 2xx (and possibly in a 1xx as well, with the same value), or the
offer is in the 2xx, and the answer is in the ACK."
This gives an idea that the 2xx also carries the answer SDP though a 1xx
response has carried the same value before.
So, it wud be great if someone could point out where "optional" is
mentioned.
--
Thanks,
Hema Ramesh.
Stephen Paterson wrote:
>Thanks Darshan,
>
>It is the fact that we require the presence of an SDP body that is the
>problem - i.e. calls fail to UAs that place the SDP in a reliable
>provisional response but not the subsequent 200. If this is an option where
>a reliable answer has been sent then we are out of spec. What I'm looking
>for is where this behaviour is defined. I don't think the RFCs are clear on
>the subject:-
>
>RFC 3261 13.2.1 2nd bullet
>
>'If the initial offer is in an INVITE, the answer MUST be in a 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.'
>
>This suggests, for an implementation covering 3261 as all UAs must, the 200
>must contain an SDP body.
>
>As I understand it, behaviour defined by 3261 will not change unless
>explicitly stated by an extension to SIP. Now, the extension in question is
>RFC 3262 (Reliability of Provisional Responses) and nowhere in this RFC does
>it modify the behaviour of the 200 response to the INVITE. In fact it
>explicitly states that the same rules are followed as defined in section
>13.2 of RFC3261.
>
>I'm fairly sure now that SDP in a 200 response to INVITE is optional and
>certainly the general consensus of the SIP implementors is that it is
>optional but I do need to know where this is stated in the RFCs.
>
>Please can someone point me in the right direction.
>
>Regards
>
>Steve
>
>-----Original Message-----
>From: Darshan Bildikar [mailto:[EMAIL PROTECTED]]
>Sent: 17 February 2006 10:56
>To: 'Stephen Paterson'; [email protected]
>Subject: RE: [Sip-implementors] Where in the specs?
>
>
>The 200 OK CAN contain an SDP even if a reliable 1XX contained an SDP. The
>proviso being that it must remain unchanged from the SDP answer in the 1XX
>response (since the offer answer is already complete).
>
>So your implementation isn't actually "incorrect" but it shouldn't require
>the SDP in 200 OK if the offer answer has already been exchanged before.
>
>Someone correct me if I'm wrong.
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]] On Behalf Of Stephen
>Paterson
>Sent: Friday, February 17, 2006 4:11 PM
>To: '[email protected]'
>Subject: [Sip-implementors] Where in the specs?
>
>Hi all,
>
>In a previous thread (No SDP in 200 reply to INVITE), Nataraju A.B. wrote:
>
>'If the 1xx responses were sent reliably then it's optional to carry the SDP
>in 200 responses.'
>
>I can't for the life of me find in the RFCs where this is stated. Please
>could you enlighten me.
>Currently our implementation requires that all 200 responses contain an SDP
>body but it seems from this thread that this behaviour is incorrect when any
>1xx + SDP response was sent reliably.
>
>Thanks in advance.
>
>Steve
>
>Steve Paterson
>Aculab
>Tel: +44 (0) 1908 273866
>Fax: +44 (0) 1908 273801
>Email: mailto:[EMAIL PROTECTED]
>Website: http://www.aculab.com
>
>_______________________________________________
>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
*********************** FSS-Private ***********************
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
