Kasturi Narayanan wrote:
> Two interpretations are around for Re-invite without SDP.
> 1) Return the Currently Negotiated SDP which is recv only
> 2) Treat that as a new SDP negotiation and return the full capabilities
> (with send-recv etc).
>
> I think the second option is more generic.
You don't want to return "full capabilities" if you don't *want* that.
In particular consider a variation on your scenario:
After Caller A and Callee B construct a dialog,
A sends a re-invite request with sdp indicates "sendonly" to hold B.
B responses 200 OK with sdp indicated "recvonly" correctly.
If at this moment, *B* sends a re-invite again but without sdp,
how does *A* response in sdp? sendreccv? recvonly?
In this case, A should respond not with its "full capabilities", but
rather with "its desired state". It had previously wanted to have the
call held, so it presumably should offer sendonly again. However, it is
possible that it was just toggled off hold but received the reinvite
before it could send its own. In that case it can offer sendrecv.
The general rule that always works if for the offerer to always offer
the state *it* desires, without regard for what it thinks the answerer
might prefer. This preserves the options for the answerer.
Consider yet another case:
- A and B have a dialog
- A reinvites with offer of sendonly to establish hold
- B answers with recvonly to acknowledge the hold
- B also decides to hold the call, so reinvites with offer
of sendonly. (What it wants.)
- A still wishes hold on its end, so doesn't want to answer
recvonly. The only valid answer consistent with what it wants
to do and with the offer is inactive, so it answers that.
- For some reason, B later sends an offerless reinvite to A.
A still wants a hold initiated by its end, but doesn't care
that call is held from other end. So it offers sendonly.
If B still wants the call held from its end as well, it will
answer with inactive. So the state stays as it was.
- Later A wants to go off hold. So it sends a reinvite with
an offer of sendrecv.
- B still wants the call held, so it answers with sendonly.
- Later, B wants to go off hold too, so it sends reinvite with
offer of sendrecv.
- A also wants to be off hold, so it answers with sendrecv.
Summarizing:
- an offer always contains what the offerer *wants*.
- an answer is computed as follows:
. select the answers that are consistent with the offer
. choose the one of those that is closest to what the
answerer *wants"
We intend to write something about this in the offeranswer draft, but
haven't yet.
Paul
> Kasturi
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 15, 2006 8:47 PM
> To: [email protected]
> Subject: [Sip-implementors] INV without sdp
>
> Hi ALL:
>
> I'm a newbie of sip implementation. Here is a question about invite
> request
> without sdp.
>
> After Caller A and Callee B construct a dialog, A sends a re-invite
> request
> with sdp indicates "sendony" to hold B. B responses 200 OK with sdp
> indicated "receonly" correctly. If at this moment, A sends a re-invite
> again but without sdp, how does B response in sdp? sendrece? receonly?
>
> Is there any sections in any RFCs defines the behavior described here?
>
> Thanks you all.
>
> BR,
> Johnny
> _______________________________________________
> 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
