| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Looks good to me! : ) From: Byron Campen
[mailto:bcampen@xxxxxxxxxxxx] Here's a diff
from my working copy. If you're familiar with the code, give it a look. *snip* Index: InviteSession.cxx =================================================================== --- InviteSession.cxx (revision 7255) +++ InviteSession.cxx (working copy) @@ -1251,6 +1251,7 @@ break; case OnAck: + case OnAckAnswer: // .bwc. Don't drop
ACK with SDP! mCurrentRetransmit200 =
0; // stop the 200 retransmit timer
handler->onAckReceived(getSessionHandle(), msg); break; Index: ServerInviteSession.cxx =================================================================== --- ServerInviteSession.cxx (revision
7255) +++ ServerInviteSession.cxx (working
copy) @@ -778,6 +778,7 @@ switch (toEvent(msg, sdp.get())) { case OnAck: + case OnAckAnswer: { mCurrentRetransmit200 =
0; // stop the 200 retransmit timer transition(Connected); @@ -785,14 +786,16 @@ break; } - case OnAckAnswer: - { - mCurrentRetransmit200 =
0; // stop the 200 retransmit timer - sendBye(); - transition(Terminated); -
handler->onTerminated(getSessionHandle(),
InviteSessionHandler::GeneralFailure, &msg); - break; - } +// .bwc. unsolicited SDP in ACK;
it would probably make sense to just +// ignore. +// case OnAckAnswer: +// { +// mCurrentRetransmit200 =
0; // stop the 200 retransmit timer +// sendBye(); +// transition(Terminated); +//
handler->onTerminated(getSessionHandle(),
InviteSessionHandler::GeneralFailure, &msg); +// break; +// } case OnCancel: { *snip* Best regards, Byron Campen
Makes
sense to me. If we can handle the call – why not try? A Warning log
is probably appropriate as a mechanism to detect non-compliant implementations. Scott From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx]
On Behalf Of Byron Campen
Looking back at this, it seems that we might want to change the code to
just silently ignore the bad SDP instead of tearing down the call. Any opinions? Best
regards, Byron
Campen
Here is SIP FAQ from SIP Expert Jonathan: If I get a new SDP body in the ACK, and I don't like
the media type, how can I indicate its unacceptable to me? It doesn't work that way. You should not get a
"new" SDP in the ACK. SDP goes in ACK only if there was no SDP in
INVITE, then SDP was included in the 200 OK. This SDP should represent a subset
of the media "offered" in the 200 OK. In other words, a normal SIP
transaction has one SDP in the INVITE, and another in 200 OK. Now, we have the
same two phase process, but the first SDP is in the 200 OK, and the second in
the ACK. Categories for this entry Last update: 2000-07-11 16:16 Author: Jonathan Rosenberg Regards, FrankY -----Original Message----- A certain UA, with "bridges in the logo" (:-) I
love that comment), is sending SDP in the ACK during the initial call setup, but
after the offer/answer has been completed in the invite/200.
This causes DUM in ServerInviteSession::dispatchAccepted() to handle the
event as OnAckAnswer and send a BYE, terminating the session. Section 13.2.1 in 3261 states some restrictions here, but
it doesn't appear that this case is spelled out. To me I can
understand how this is considered bad behavior, with no way to answer this new
offer in the ACK. Question is, is sending a BYE too harsh here? Could
this decision be left up to the APP? For example, if the SDP is the same
as the initial INVITE, just ignore this behavior? UAC
UAS INVITE w/offer -> 200 OK w/answer <- ACK w/SDP -> BYE <- ACK -> Thanks, -Justin _______________________________________________ resiprocate-devel mailing list resiprocate-devel@xxxxxxxxxxxxxxxxxxxx https://list.resiprocate.org/mailman/listinfo/resiprocate-devel _______________________________________________ resiprocate-devel
mailing list _______________________________________________ resiprocate-devel mailing list |