[Sip-implementors] RE-INVITE QUESTION

2016-02-04 Thread Roman Romenskyi
Hello,

 If anyone have an idea:
UAC sends RE-INVITE, than send CANCEL request, is this situation is
correct? Because dialog state is connected, and 200 OK for a first
INVITE are sent.
How We should process it? Please point me to rfc.

Best regards, Roman.
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


Re: [Sip-implementors] RE-INVITE QUESTION

2016-02-04 Thread Anand Konji
Hi,

Following info might help you,

Refer rfc 6141 section 3.8,

*3.8* *. Clarifications on
Canceling Re-INVITEs*

Section 9.2 of RFC 3261  [
RFC3261 ] specifies the behavior of a
UAS responding to a CANCEL request. Such a UAS responds to the INVITE
request with a 487 (Request Terminated) at the SHOULD level. Per the rules
specified in Section 3.3 ,
if the INVITE request was a re-INVITE and some of its requested changes had
already been executed, the UAS would return a 2xx response instead.

Regards,
Anand
On Feb 4, 2016 9:41 PM, "Roman Romenskyi"  wrote:

> Hello,
>
>  If anyone have an idea:
> UAC sends RE-INVITE, than send CANCEL request, is this situation is
> correct? Because dialog state is connected, and 200 OK for a first
> INVITE are sent.
> How We should process it? Please point me to rfc.
>
> Best regards, Roman.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


Re: [Sip-implementors] RE-INVITE QUESTION

2016-02-04 Thread Paul Kyzivat

On 2/4/16 11:11 AM, Roman Romenskyi wrote:

Hello,

  If anyone have an idea:
UAC sends RE-INVITE, than send CANCEL request, is this situation is
correct? Because dialog state is connected, and 200 OK for a first
INVITE are sent.
How We should process it? Please point me to rfc.


CANCEL has nothing to do with dialogs, only with transactions. So the 
fact that the reinvite is within a dialog has no bearing on the question.


(Or are you concerned about the use of the 481 response to CANCEL. Note 
that 481 has two distinct meanings: for CANCEL it means there is no 
matching *transaction*. Other things it means there is no matching 
*dialog*. For CANCEL 481 *does not* say anything about the dialog.)


Note that you can *never* be sure when you send a CANCEL that it will be 
received in time to be effective. It is always possible that the request 
was already processed before the CANCEL was handled. For the recipient, 
handling CANCEL should typically be on a best-effort basis. (But you 
won't find that in the spec.) You aren't *obligated* to expedite it 
through your request processing.


Note that CANCEL is more likely to be effective on an initial INVITE, 
because the invite is likely to pause for alerting, giving time to 
process a CANCEL. A reinvite is likely to be much quicker, and perhaps 
to be processed synchronously, so that there is little opportunity to 
notice a CANCEL. Also, as specified in section 9.1 of 3261, the CANCEL 
can't be sent until a provisional response has been received, nor after 
a final response has been received.


I find that section 9 of 3261 is pretty clear. What are you confused 
about? Note that there is a clarification on cancelling reinvite in 
RFC6141, but I don't think it is pertinent to this discussion.


Thanks,
Paul



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


Re: [Sip-implementors] RE-INVITE question 14.2

2008-04-14 Thread Ranjith.V
Hi Richard,

No of m-lines (Media lines) MUST same in offer and answer. So Bob
MUST not send D,E media information in 200-0K of INVITE

Refer section 6 of RFC 3264
  For each m= line in the offer, there MUST be a corresponding m=
   line in the answer.  The answer MUST contain exactly the same number
   of m= lines as the offer

If Bob want to send offer in 200 OK, he can send altogether different offer
With out violating following condition.
if the previous SDP had N m= lines, the new SDP MUST have at least N m= 
lines

Please refer section 8 of RFC 3264 for more details.

Regards
Ranjith



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Wu
Sent: Monday, April 14, 2008 3:37 PM
To: sip-implementors@lists.cs.columbia.edu
Cc: Fu Siu Ming Claudio
Subject: [Sip-implementors] RE-INVITE question 14.2

Hi All,

In RFC 3264 chapter 14.2
A UAS providing an offer in a 2xx (because the INVITE did not contain
an offer) SHOULD construct the offer as if the UAS were making a brand
new call, subject .

Consider the following scenario:

alice- INVITE with SDP media A, B, C --- bob  /* all are sendrecv */

alice- 200OK with SDP media A, B, C, D, E  bob /* all are
sendrecv */

alice-- ACK  bob

Then alice hold bob

alice- INVITE with SDP media A, B, C --- bob  /* all are sendonly */

alice- 200OK with SDP media A, B, C, D, E  bob /* all are
recvonly */

alice-- ACK  bob

Afterwards,
alice send a RE-INVITE with no SDP

alice- INVITE with no SDP--- bob
What should bob rely? Suppose bob support five medias A, B, C, D, and E.

Thanks in advance.

ichardR



~
This message (including any attachments) is for the named
addressee(s)'s use only. It may contain sensitive, confidential,
private proprietary or legally privileged information intended for a
specific individual and purpose, and is protected by law. If you are
not the intended recipient, please immediately delete it and all copies
of it from your system, destroy any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of
this message and/or any attachments is strictly prohibited.


___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

DISCLAIMER: This message is proprietary to Aricent  and is intended solely for 
the use of 
the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you 
have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this 
message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this 
email including damage from virus.

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


[Sip-implementors] RE-INVITE question 14.2

2008-04-14 Thread Richard Wu
Hi All,
   
In RFC 3264 chapter 14.2
A UAS providing an offer in a 2xx (because the INVITE did not contain 
an offer) SHOULD construct the offer as if the UAS were making a brand 
new call, subject .

Consider the following scenario:

alice- INVITE with SDP media A, B, C --- bob  /* all are sendrecv */

alice- 200OK with SDP media A, B, C, D, E  bob /* all are 
sendrecv */

alice-- ACK  bob

Then alice hold bob

alice- INVITE with SDP media A, B, C --- bob  /* all are sendonly */

alice- 200OK with SDP media A, B, C, D, E  bob /* all are 
recvonly */

alice-- ACK  bob

Afterwards,
alice send a RE-INVITE with no SDP

alice- INVITE with no SDP--- bob
What should bob rely? Suppose bob support five medias A, B, C, D, and E.

Thanks in advance.

ichardR



~
This message (including any attachments) is for the named
addressee(s)'s use only. It may contain sensitive, confidential,
private proprietary or legally privileged information intended for a
specific individual and purpose, and is protected by law. If you are
not the intended recipient, please immediately delete it and all copies
of it from your system, destroy any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of
this message and/or any attachments is strictly prohibited.


___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


Re: [Sip-implementors] RE-INVITE question 14.2

2008-04-14 Thread Paul Kyzivat

Ranjith.V wrote:
 Hi Richard,
 
 No of m-lines (Media lines) MUST same in offer and answer. So Bob
 MUST not send D,E media information in 200-0K of INVITE

True. This applies to answers, not offers.
The offer in a reinvite must have *at least* as many m-lines as the 
prior o/a.

The original scenario is a little unclear. When it says with SDP media 
A, B, C, D, E it might mean 5 m-lines, or one m-line with five payload 
types. I am assuming it meant five m-lines.

On that assumption the two shown answers are invalid.

I think this is what Ranjith is saying.

 Refer section 6 of RFC 3264
   For each m= line in the offer, there MUST be a corresponding m=
line in the answer.  The answer MUST contain exactly the same number
of m= lines as the offer
 
 If Bob want to send offer in 200 OK, he can send altogether different offer
 With out violating following condition.

Yes. This is where it would be fine for Bob to include all five m-lines 
if it wants. Then, if Alice doesn't want D and E she may refuse them by 
setting the port numbers to zero in the answer.

Paul

 if the previous SDP had N m= lines, the new SDP MUST have at least N m= 
 lines
 
 Please refer section 8 of RFC 3264 for more details.
 
 Regards
 Ranjith
 
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Wu
 Sent: Monday, April 14, 2008 3:37 PM
 To: sip-implementors@lists.cs.columbia.edu
 Cc: Fu Siu Ming Claudio
 Subject: [Sip-implementors] RE-INVITE question 14.2
 
 Hi All,
 
 In RFC 3264 chapter 14.2
 A UAS providing an offer in a 2xx (because the INVITE did not contain
 an offer) SHOULD construct the offer as if the UAS were making a brand
 new call, subject .
 
 Consider the following scenario:
 
 alice- INVITE with SDP media A, B, C --- bob  /* all are sendrecv */
 
 alice- 200OK with SDP media A, B, C, D, E  bob /* all are
 sendrecv */
 
 alice-- ACK  bob
 
 Then alice hold bob
 
 alice- INVITE with SDP media A, B, C --- bob  /* all are sendonly */
 
 alice- 200OK with SDP media A, B, C, D, E  bob /* all are
 recvonly */
 
 alice-- ACK  bob
 
 Afterwards,
 alice send a RE-INVITE with no SDP
 
 alice- INVITE with no SDP--- bob
 What should bob rely? Suppose bob support five medias A, B, C, D, and E.
 
 Thanks in advance.
 
 ichardR
 
 
 
 ~
 This message (including any attachments) is for the named
 addressee(s)'s use only. It may contain sensitive, confidential,
 private proprietary or legally privileged information intended for a
 specific individual and purpose, and is protected by law. If you are
 not the intended recipient, please immediately delete it and all copies
 of it from your system, destroy any hard copies of it
 and notify the sender. Any use, disclosure, copying, or distribution of
 this message and/or any attachments is strictly prohibited.
 
 
 ___
 Sip-implementors mailing list
 Sip-implementors@lists.cs.columbia.edu
 https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
 
 DISCLAIMER: This message is proprietary to Aricent  and is intended solely 
 for the use of 
 the individual to whom it is addressed. It may contain privileged or 
 confidential information and should not be 
 circulated or used for any purpose other than for what it is intended. If you 
 have received this message in error, 
 please notify the originator immediately. If you are not the intended 
 recipient, you are notified that you are strictly
 prohibited from using, copying, altering, or disclosing the contents of this 
 message. Aricent accepts no responsibility for 
 loss or damage arising from the use of the information transmitted by this 
 email including damage from virus.
 
 ___
 Sip-implementors mailing list
 Sip-implementors@lists.cs.columbia.edu
 https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors