Re: [Sip-implementors] RE-INVITE question 14.2
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
Re: [Sip-implementors] The Precondition Quesiton - End-to-End statustype Segmented Status type
Up this message again, if no response yet. Alex Zhang ESN: 6-554-8782 -Original Message- From: Alex Zhang (GDNTRND) Sent: Saturday, April 12, 2008 11:40 PM To: Alex Zhang (GDNTRND); sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] The Precondition Quesiton - End-to-End statustype Segmented Status type Anybody can give some input for this question? Thanks a lot! Alex Zhang ESN: 6-554-8782 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 11, 2008 9:55 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] The Precondition Quesiton - End-to-End statustype Segmented Status type Hi All, Can any of you explain what actual meaning of the End-to-End status type Segmented Status type in the Precondition Scenario is? It is noticed that for the Segment Status Type, it represents the Access Side of the User Agent. Here can anybody give an example of the Access Side? Also, what is the end-to-end for a UA (UAC or UAS)? And, does anybody have a related explanation for the MGCF/SIP-I PC applying example, in which the Media Gateway is involved in the bearer? I am not sure how the Access Side and the end-to-end is defined in thiskind of cases. Thanks, ___ 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
[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
Re: [Sip-implementors] RE-INVITE question 14.2
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
Re: [Sip-implementors] Offer/Answer question
I agree with Paul; however I'll highlight the rfc3311 section 5.2 text concerning UPDATE with SDP potentially triggering a 504. Thus UAC receiving 504 for UPDATE with SDP should be aware that a re-INVITE might be needed to perform the SDP modification. If the UAS cannot change the session parameters without prompting the user, it SHOULD reject the request with a 504 response. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Monday, April 14, 2008 12:34 AM To: Manpreet Singh Cc: Bob Penfield; [EMAIL PROTECTED]; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Offer/Answer question Manpreet Singh wrote: Wasn't denying the use of update on confirmed dialog, just saying the recommended use of UPDATE is for early dialog and not for confirmed based on the spec. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE. IMO the denial is a bit overstated. It is only pointing out that its inappropriate if the offer it carries will require an extended time for approval before being answered. If that isn't to be the case then there isn't any issue with using UPDATE. Note that the issue with immediate response also applies to an UPDATE used during an early dialog. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Offer/Answer question
That's one reason why I have seen most implementations use re-invites instead of updates for mid call changes. Why leave a possibility of 2 transactions when one can live with 1. But then its implementation specific :-) Thnx -Original Message- From: Brett Tate [EMAIL PROTECTED] To: Manpreet Singh CC: [EMAIL PROTECTED] [EMAIL PROTECTED]; sip-implementors@lists.cs.columbia.edu sip-implementors@lists.cs.columbia.edu Sent: Mon Apr 14 09:04:10 2008 Subject: RE: [Sip-implementors] Offer/Answer question I agree with Paul; however I'll highlight the rfc3311 section 5.2 text concerning UPDATE with SDP potentially triggering a 504. Thus UAC receiving 504 for UPDATE with SDP should be aware that a re-INVITE might be needed to perform the SDP modification. If the UAS cannot change the session parameters without prompting the user, it SHOULD reject the request with a 504 response. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Monday, April 14, 2008 12:34 AM To: Manpreet Singh Cc: Bob Penfield; [EMAIL PROTECTED]; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Offer/Answer question Manpreet Singh wrote: Wasn't denying the use of update on confirmed dialog, just saying the recommended use of UPDATE is for early dialog and not for confirmed based on the spec. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE. IMO the denial is a bit overstated. It is only pointing out that its inappropriate if the offer it carries will require an extended time for approval before being answered. If that isn't to be the case then there isn't any issue with using UPDATE. Note that the issue with immediate response also applies to an UPDATE used during an early dialog. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Offer/Answer question
Agree with session refresh(without o/a in specific). Makes call flow simplistic and in lots of cases avoids interoperability issues caused due to o/a wth re-invites Thnx -Original Message- From: Paul Kyzivat [EMAIL PROTECTED] To: Manpreet Singh CC: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; sip-implementors@lists.cs.columbia.edu sip-implementors@lists.cs.columbia.edu Sent: Mon Apr 14 09:30:57 2008 Subject: Re: [Sip-implementors] Offer/Answer question Manpreet Singh wrote: That's one reason why I have seen most implementations use re-invites instead of updates for mid call changes. Why leave a possibility of 2 transactions when one can live with 1. But then its implementation specific :-) Sometimes the call flow won't work right if a human delay is inserted in it. In that case UPDATE is ideal because it prevents that eventuality. The 3pcc call flow RFC (I forget the number) is getting a bit long in the tooth now, but it it talks about some cases with that kind of constraint. UPDATE is also useful without o/a for session timer refresh. Paul Thnx -Original Message- From: Brett Tate [EMAIL PROTECTED] To: Manpreet Singh CC: [EMAIL PROTECTED] [EMAIL PROTECTED]; sip-implementors@lists.cs.columbia.edu sip-implementors@lists.cs.columbia.edu Sent: Mon Apr 14 09:04:10 2008 Subject: RE: [Sip-implementors] Offer/Answer question I agree with Paul; however I'll highlight the rfc3311 section 5.2 text concerning UPDATE with SDP potentially triggering a 504. Thus UAC receiving 504 for UPDATE with SDP should be aware that a re-INVITE might be needed to perform the SDP modification. If the UAS cannot change the session parameters without prompting the user, it SHOULD reject the request with a 504 response. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Monday, April 14, 2008 12:34 AM To: Manpreet Singh Cc: Bob Penfield; [EMAIL PROTECTED]; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Offer/Answer question Manpreet Singh wrote: Wasn't denying the use of update on confirmed dialog, just saying the recommended use of UPDATE is for early dialog and not for confirmed based on the spec. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE. IMO the denial is a bit overstated. It is only pointing out that its inappropriate if the offer it carries will require an extended time for approval before being answered. If that isn't to be the case then there isn't any issue with using UPDATE. Note that the issue with immediate response also applies to an UPDATE used during an early dialog. Paul ___ 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
