[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
"If the offer occurs in the 200 class response, the UAC
MUST send an ACK request, with a valid answer. It MAY send a BYE
request to terminate the call, or MAY generate a re-INVITE, with the
offer in the INVITE, to change the session parameters back to an
acceptable form."
Comments?
Best Regards,
Chris
Chris Hogg
Nortel Networks (UK)
-----Original Message-----
From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr]
Sent: 04 October 2001 16:31
To: Hogg, Chris [MDN05:EP30:EXCH]
Cc: 'stoshniwal@hss.hns.com'; 'Christer Holmberg'; brett@broadsoft.com;
sip@ietf.org
Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx
Hi,
So, can I conclude saying that if there was no SDP in the Invite (or
re-Invite), the SDP that can be sent by UA-A on an ACK message can only be a
subset of the SDP received in the 200 message ?
In other words, the UA sending the ACK (which is the same that sent the
Invite w/o SDP) cannot improve the session description in this case.
This way of reasonning seems to be very logic. If the UA-A is not happy with
this SDP, can he still issue a CANCEL message, followed by a new re-Invite
with modified SDP ?
Is this the correct interpretation ?
Best regards
Juan Carlos
"Chris Hogg" <chogg@nortelnetworks.com> on 04/10/2001 16:34:56
To: "'stoshniwal@hss.hns.com'" <stoshniwal@hss.hns.com>
cc: "'Christer Holmberg'"
<christer.holmberg@lmf.ericsson.se>,
brett@broadsoft.com, sip@ietf.org(bcc: Juan-Carlos
ROJAS/FR/ALCATEL)
Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in
2xx
Hi everyone,
Siddharth's scenario is very similar to the one I was discussing with the
3pcc. Amalgamating my scerario with the one described below, "A" in
Siddharth's example is equivalent to my "controller"(C). Thus after the
original INV/200/ACK transaction A may send a Re-INVITE to put B on hold.
But A may then subsequently send a Re-INVITE with no SDP to B. B will reply
with its' current SDP which may be hold or unhold SDP. The ACK from A may
contain modified SDP (i.e. modified as a result of the controller talking to
some other SIP UA) but I do not think it should add any new media streams.
Comments?
Regards
Chris
Chris Hogg
Nortel Networks (UK).
-----Original Message-----
From: stoshniwal@hss.hns.com [mailto:stoshniwal@hss.hns.com]
Sent: 04 October 2001 14:59
To: Hogg, Chris [MDN05:EP30:EXCH]
Cc: 'Christer Holmberg'; brett@broadsoft.com; sip@ietf.org
Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx
Hi everyone,
Please find my comments below...
>> I am not sure I agree on that. Isn't the 200 for a non-SDP
>> re-INVITE supposed to return the current remote SDP, and if
>> the call has been put on hold that should be a call-hold
>> SDP (ie the SDP that was returned in the 200 for the call
>> hold re-INVITE)?
Just to confirm, the scenario we are talking about is
User A <-----> User B established with 2 streams (say)
User A -----> User B re-INVITE Hold both streams
User A <------ User B 200 OK with Hold SDP (2 way hold)
User A -----> User B ACK and session is on hold now.
NOW...
User A -----> User B a re-INVITE w/o SDP
Is this correct?
If so, I have a feeling I agree with Brett. A response to a
re-INVITE w/o SDP need not have a held SDP even if the UAS
was earlier put on hold.
REASON: On the list it had earlier been agreed that change
of IP and/or port in ANY offer after the original INVITE
is allowed. In case of responding to a re-INVITE w/o SDP,
the offer is in the 200 OK to this re-INVITE. The UA SHOULD
be allowed to send either of:
1. A hold SDP (like the previous 200 OK response that it sent)
if it still wants A to be on hold.
2. A unhold SDP as this involves only a change of IP (or
media stream) as it may now want User A to come off hold.
What the UAS MUST NOT do is add a third stream (in addition
to the 2 already accepted originally). It is free to put one
or more of the 2 "originally in use streams" on/off hold.
Comments please?
Best regards,
Siddharth.
=================================
Siddharth Toshniwal
Software Engineer
Hughes Software Systems, Bangalore
http://www.hssworld.com
------_=_NextPart_001_01C14D83.9C165B90
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Hi Juan Carlos,</FONT>
</P>
<P><FONT SIZE=3D2>>So, can I conclude saying that if there was no =
SDP in the Invite (or re-Invite), the SDP >that can be sent by =
UA-A on an ACK message can only be a subset of the SDP received in the =
>200 message ?</FONT></P>
<P><FONT SIZE=3D2>Yes I think this is how the appendix B of bis intends =
this to work - In the case of a re-INVITE with no SDP the =
"offer" is in the 200 OK and the "answer" is in the =
ACK. According to appendix B, what the UAS can offer in this case =
is governed by:</FONT></P>
<P><FONT SIZE=3D2>"the offerer SHOULD offer the same SDP it</FONT>
<BR><FONT SIZE=3D2> provided previously if it has no reason =
to change anything." (In the case of a 200 OK offer).</FONT>
</P>
<P><FONT SIZE=3D2>>In other words, the UA sending the ACK (which is =
the same that sent the Invite w/o SDP) </FONT>
<BR><FONT SIZE=3D2>>cannot improve the session description in this =
case.</FONT>
</P>
<P><FONT SIZE=3D2>The "answer" is contained within the =
ACK. Appendix B seems to indicate that even if the =
"offer" did not change anything from the previous SDP (i.e. =
it is effectively a no-op) that the "answer" may contain SDP =
which is the same as the previous SDP from the answerer or MAY be =
different. However, the constraint in constructing all answers =
means that the answer "The answer to offered SDP is based on the =
offered SDP" (see section B.3) i.e. it must contain the same =
number of "m=3D" lines. Of course, if the UA doesn't =
like the offered streams in the 200 OK it can always reject them by =
setting the port to 0. </FONT></P>
<P><FONT SIZE=3D2>So in answer to your question, I think the 200 OK can =
update the session description compared to that of the previous SDP if =
it has a reason to change something in the session description but the =
ACK MUST contain the answer which is based on this offer.</FONT></P>
<P><FONT SIZE=3D2>>If the UA-A is not happy with this SDP, can he =
still issue a CANCEL message, followed by a >new re-Invite with =
modified SDP ?</FONT></P>
<P><FONT SIZE=3D2>Yes, I think this is ok.</FONT>
</P>
<P><FONT SIZE=3D2>From Appendix B</FONT>
</P>
<P><FONT SIZE=3D2>"If the offer occurs in the 200 class response, =
the UAC</FONT>
<BR><FONT SIZE=3D2> MUST send an ACK request, with a valid =
answer. It MAY send a BYE</FONT>
<BR><FONT SIZE=3D2> request to terminate the call, or MAY =
generate a re-INVITE, with the</FONT>
<BR><FONT SIZE=3D2> offer in the INVITE, to change the =
session parameters back to an</FONT>
<BR><FONT SIZE=3D2> acceptable form."</FONT>
</P>
<P><FONT SIZE=3D2>Comments?</FONT>
</P>
<P><FONT SIZE=3D2>Best Regards,</FONT>
</P>
<P><FONT SIZE=3D2>Chris</FONT>
</P>
<P><FONT SIZE=3D2>Chris Hogg</FONT>
<BR><FONT SIZE=3D2>Nortel Networks (UK)</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Juan-Carlos.Rojas@alcatel.fr [<A =
HREF=3D"mailto:Juan-Carlos.Rojas@alcatel.fr">mailto:Juan-Carlos.Rojas@al=
catel.fr</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: 04 October 2001 16:31</FONT>
<BR><FONT SIZE=3D2>To: Hogg, Chris [MDN05:EP30:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'stoshniwal@hss.hns.com'; 'Christer Holmberg'; =
brett@broadsoft.com;</FONT>
<BR><FONT SIZE=3D2>sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Sip] Open Issue #58: Rejected mid-call =
SDP in 2xx</FONT>
</P>
<BR>
<BR>
<BR>
<P><FONT SIZE=3D2>Hi,</FONT>
</P>
<P><FONT SIZE=3D2>So, can I conclude saying that if there was no SDP in =
the Invite (or re-Invite), the SDP that can be sent by UA-A on an ACK =
message can only be a subset of the SDP received in the 200 message =
?</FONT></P>
<P><FONT SIZE=3D2>In other words, the UA sending the ACK (which is the =
same that sent the Invite w/o SDP) cannot improve the session =
description in this case.</FONT></P>
<P><FONT SIZE=3D2>This way of reasonning seems to be very logic. If the =
UA-A is not happy with this SDP, can he still issue a CANCEL message, =
followed by a new re-Invite with modified SDP ?</FONT></P>
<P><FONT SIZE=3D2>Is this the correct interpretation ?</FONT>
</P>
<P><FONT SIZE=3D2>Best regards</FONT>
</P>
<P><FONT SIZE=3D2> Juan Carlos</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<P><FONT SIZE=3D2>"Chris Hogg" =
<chogg@nortelnetworks.com> on 04/10/2001 16:34:56</FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT SIZE=3D2> To: =
"'stoshniwal@hss.hns.com'" <stoshniwal@hss.hns.com> =
</FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT SIZE=3D2> cc: =
"'Christer =
Holmberg'" &nb=
sp; &nb=
sp; </FONT>
<BR><FONT =
SIZE=3D2> =
<christer.holmberg@lmf.ericsson.se>, =
</FONT>
<BR><FONT =
SIZE=3D2> =
brett@broadsoft.com, sip@ietf.org(bcc: Juan-Carlos </FONT>
<BR><FONT =
SIZE=3D2> =
ROJAS/FR/ALCATEL) &=
nbsp; &=
nbsp; &=
nbsp; </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT SIZE=3D2> Subject: RE: [Sip] Open Issue #58: Rejected =
mid-call SDP in </FONT>
<BR><FONT =
SIZE=3D2> =
2xx &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<P><FONT SIZE=3D2>Hi everyone,</FONT>
</P>
<P><FONT SIZE=3D2>Siddharth's scenario is very similar to the one I was =
discussing with the</FONT>
<BR><FONT SIZE=3D2>3pcc. Amalgamating my scerario with the one =
described below, "A" in</FONT>
<BR><FONT SIZE=3D2>Siddharth's example is equivalent to my =
"controller"(C). Thus after the</FONT>
<BR><FONT SIZE=3D2>original INV/200/ACK transaction A may send a =
Re-INVITE to put B on hold.</FONT>
<BR><FONT SIZE=3D2>But A may then subsequently send a Re-INVITE with no =
SDP to B. B will reply</FONT>
<BR><FONT SIZE=3D2>with its' current SDP which may be hold or unhold =
SDP. The ACK from A may</FONT>
<BR><FONT SIZE=3D2>contain modified SDP (i.e. modified as a result of =
the controller talking to</FONT>
<BR><FONT SIZE=3D2>some other SIP UA) but I do not think it should add =
any new media streams.</FONT>
</P>
<P><FONT SIZE=3D2>Comments?</FONT>
</P>
<P><FONT SIZE=3D2>Regards</FONT>
</P>
<P><FONT SIZE=3D2>Chris</FONT>
</P>
<P><FONT SIZE=3D2>Chris Hogg</FONT>
<BR><FONT SIZE=3D2>Nortel Networks (UK).</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: stoshniwal@hss.hns.com [<A =
HREF=3D"mailto:stoshniwal@hss.hns.com">mailto:stoshniwal@hss.hns.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: 04 October 2001 14:59</FONT>
<BR><FONT SIZE=3D2>To: Hogg, Chris [MDN05:EP30:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'Christer Holmberg'; brett@broadsoft.com; =
sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Sip] Open Issue #58: Rejected mid-call =
SDP in 2xx</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<P><FONT SIZE=3D2>Hi everyone,</FONT>
</P>
<P><FONT SIZE=3D2>Please find my comments below...</FONT>
</P>
<P><FONT SIZE=3D2>>> I am not sure I agree on that. Isn't the 200 =
for a non-SDP</FONT>
<BR><FONT SIZE=3D2>>> re-INVITE supposed to return the current =
remote SDP, and if</FONT>
<BR><FONT SIZE=3D2>>> the call has been put on hold that should =
be a call-hold</FONT>
<BR><FONT SIZE=3D2>>> SDP (ie the SDP that was returned in the =
200 for the call</FONT>
<BR><FONT SIZE=3D2>>> hold re-INVITE)?</FONT>
</P>
<P><FONT SIZE=3D2>Just to confirm, the scenario we are talking about =
is</FONT>
</P>
<P><FONT SIZE=3D2>User A <-----> User B =
established with 2 streams (say)</FONT>
<BR><FONT SIZE=3D2>User A -----> User B =
re-INVITE Hold both streams</FONT>
<BR><FONT SIZE=3D2>User A <------ User B 200 OK =
with Hold SDP (2 way hold)</FONT>
<BR><FONT SIZE=3D2>User A -----> User B ACK =
and session is on hold now.</FONT>
</P>
<P><FONT SIZE=3D2>NOW...</FONT>
<BR><FONT SIZE=3D2>User A -----> User B a =
re-INVITE w/o SDP</FONT>
</P>
<P><FONT SIZE=3D2>Is this correct?</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>If so, I have a feeling I agree with Brett. A =
response to a</FONT>
<BR><FONT SIZE=3D2>re-INVITE w/o SDP need not have a held SDP even if =
the UAS</FONT>
<BR><FONT SIZE=3D2>was earlier put on hold.</FONT>
</P>
<P><FONT SIZE=3D2>REASON: On the list it had earlier been agreed that =
change</FONT>
<BR><FONT SIZE=3D2>of IP and/or port in ANY offer after the original =
INVITE</FONT>
<BR><FONT SIZE=3D2>is allowed. In case of responding to a re-INVITE w/o =
SDP,</FONT>
<BR><FONT SIZE=3D2>the offer is in the 200 OK to this re-INVITE. The UA =
SHOULD</FONT>
<BR><FONT SIZE=3D2>be allowed to send either of:</FONT>
</P>
<P><FONT SIZE=3D2>1. A hold SDP (like the previous 200 OK response that =
it sent)</FONT>
<BR><FONT SIZE=3D2> if it still wants A to be on =
hold.</FONT>
<BR><FONT SIZE=3D2>2. A unhold SDP as this involves only a change of IP =
(or</FONT>
<BR><FONT SIZE=3D2> media stream) as it may now want User A =
to come off hold.</FONT>
</P>
<P><FONT SIZE=3D2>What the UAS MUST NOT do is add a third stream (in =
addition</FONT>
<BR><FONT SIZE=3D2>to the 2 already accepted originally). It is free to =
put one</FONT>
<BR><FONT SIZE=3D2>or more of the 2 "originally in use =
streams" on/off hold.</FONT>
</P>
<P><FONT SIZE=3D2>Comments please?</FONT>
</P>
<P><FONT SIZE=3D2>Best regards,</FONT>
<BR><FONT SIZE=3D2>Siddharth.</FONT>
</P>
<P><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>Siddharth Toshniwal</FONT>
<BR><FONT SIZE=3D2>Software Engineer</FONT>
<BR><FONT SIZE=3D2>Hughes Software Systems, Bangalore</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.hssworld.com" =
TARGET=3D"_blank">http://www.hssworld.com</A></FONT>
</P>
<BR>
<BR>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C14D83.9C165B90--
_______________________________________________
Sip mailing list http://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