Re: About offeranswer draft:
Eric wang <[email protected]> Wed, 14 Apr 2010 13:04:34 +0800
| Newsgroups | gmane.ietf.sipping |
|---|---|
| Message-ID | <[email protected]> |
Hi all,
I believe that SDP in non-reliable response is useful. eg, if the UAS
wants to send a tone to UAC while the UAC doesn't support 100rel, the UAS
can use a non-reliable response with the tone SDP.
So I believe different SDPs(compare with the answer) can exist in
non-reliable response and final 2xx response.
But, when I saw the chart below, the only words in my mind is ,"OMG, the
SIP is never SI(m)P(le) again!"
2010/4/14 OKUMURA Shinji <[email protected]>
> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.
> (Rc4) should treat SDP4 as the answer and confirm the current O/A status
> by sending new offer.
>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>
> SDP5 and SDP7 are regarded as "subsequent offers".
>
> What do you think of these?
>
> Regards,
> Shinji
>
> [email protected]
> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >
> >[email protected] 写于 2010-04-12 10:55:47:
> >
> >> Hi Gao,
> >>
> >> The clarifications for the section 13.2.1 of RFC 3261 is
> >> one of the major purposes in this draft.
> >>
> >> In the section 3.1 of this draft,
> >> | 3.1. Offer/Answer for the INVITE method with 100rel extension
> >> | (snip) All the session
> >> | descriptions in the unreliable responses to the INVITE request must
> >> | be identical to the answer which is included in the reliable
> >> | response.
> >>
> >> Do you doubt this clarification?
> >> In my understanding, this has already reached the consensus in WG.
> >
> >[Gao] I am not want to *challenge* the consensus we have reached in WG.
> >But as this draft is aims for clarification, not for normative correction,
> >I have no way to convince the *UAS*.
> >
> >>
> >> I'm confused.
> >> Do you have something a concrete proposal?
> >
> >[Gao] I think the original illegibility is from RFC3261. So, I sended
> >mails about it in SIPCore ML:
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> >To be honest, I think there are two options here:
> >1. Forbid different SDP(compare with the answer) before the answer
> >normatively.
> >2. Allowing different SDP(compare with the answer) before the answer
> >normatively.
> >
> >>
> >> Just to be sure, this draft is not a normative document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>
> >> [email protected]
> >> Fri, 9 Apr 2010 16:50:12 +0800
> >> >Hi Shinji,
> >> >
> >> >Thanks firstly.
> >> >
> >> >But the UAS do not think it throws the problem. RFC3261 said UAS may
> send
> >> >the same SDP before the answer, but there is not normative words of to
> >> >forbid the different SDPs.
> >> >
> >> >And if the equipment has been in the network, unless we using the
> evident
> >> >standard, we has no way to request their correction.
> >> >
> >> >Gao
> >> >
> >> >OKUMURA Shinji <[email protected]>
> >> >发件人: [email protected]
> >> >2010-04-09 16:30
> >> >
> >> >收件人
> >> >[email protected]
> >> >抄送
> >> >
> >> >主题
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >Hi Gao,
> >> >
> >> >In this case it is no doubt the UAS is a cause of the problem.
> >> >All you have to do is say "Your UAS is against the rules".
> >> >You will surely win the fight.
> >> >
> >> >Regards,
> >> >Shinji
> >> >
> >> >[email protected]
> >> >Fri, 9 Apr 2010 15:25:58 +0800
> >> >>Hi Shinji,
> >> >>
> >> >>By myself, I am OK with the three ways. But if there's no normative
> >> >>definition here, there would be some interworking fight for this
> issue.
> >> >>
> >> >>Thanks,
> >> >>
> >> >>Gao
> >> >>
> >> >>OKUMURA Shinji <[email protected]>
> >> >>发件人: [email protected]
> >> >>2010-04-09 14:23
> >> >>
> >> >>收件人
> >> >>[email protected]
> >> >>抄送
> >> >>
> >> >>主题
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>Hi Gao,
> >> >>
> >> >>Considering a BCP recommendation in this case,
> >> >>
> >> >>>When UAC receives the different SDP in a reliable response from
> >> >>>the prior one in a non-reliable response, UAC may ...
> >> >>>1. terminate the session.
> >> >>>2. keep using the SDP in a non-reliable response.
> >> >>>3. change to the SDP in a reliable response.
> >> >>
> >> >>and,
> >> >>4. In case 2 or 3, it is recommended that the UAC confirms the current
> >> >> offer-answer status using a reINVITE or an UPDATE request.
> >> >>
> >> >>However I think "may" is adequate in case 3.
> >> >>
> >> >>Regards,
> >> >>Shinji
> >> >>
> >> >>[email protected]
> >> >>Fri, 9 Apr 2010 11:44:34 +0800
> >> >>>Hi,
> >> >>>
> >> >>>Yes, considering implementation, I also find the three ways,
> especially
> >> >>>for the last two ways.
> >> >>>
> >> >>>My original thought is make clarification on the third one("3. change
> to
> >> >>>the SDP in a reliable response"), by RFC3264's rule.
> >> >>>
> >> >>>In fact, I think by rules, the UAC should modify the session as it is
> the
> >> >>>lawful answer. Using early media by the SDP prior to the lawful
> answer is
> >> >>>something outside of the lawful rules(Reliably way of using
> earlymedia is
> >> >>>Answer in 100rel).
> >> >>>
> >> >>>So, I think using or just discarding the SDP prior to the lawful
> answer is
> >> >>>something depends on implementation. While "change to the SDP in a
> >> >>>reliable response" should be normative.
> >> >>>
> >> >>>Thanks,
> >> >>>
> >> >>>Gao
> >> >>>
> >> >>>OKUMURA Shinji <[email protected]>
> >> >>>发件人: [email protected]
> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>收件人
> >> >>>[email protected]
> >> >>>抄送
> >> >>>
> >> >>>主题
> >> >>>Re: [Sipping] About offeranswer draft:
> >> >>>
> >> >>>Hi Gao,
> >> >>>
> >> >>>I have no doubt that the different SDP in non-reliable response
> >> >>>violates current regulations.
> >> >>>
> >> >>>The behaviour of UAC is an implementation issue, I think.
> >> >>>When UAS receives the different SDP in a reliable response from
> >> >>>the prior one in a non-reliable response, UAS may ...
> >> >>>1. terminate the session.
> >> >>>2. keep using the SDP in a non-reliable response.
> >> >>>3. change to the SDP in a reliable response.
> >> >>>
> >> >>>It is not clear, but it is not a regular case.
> >> >>>
> >> >>>Regards,
> >> >>>Shinji
> >> >>>
> >> >>>[email protected]
> >> >>>Wed, 7 Apr 2010 11:14:07 +0800
> >> >>>>Hi Paul,
> >> >>>>
> >> >>>>While considering one problem in our production's interoperability
> >> >>>>testing, I re-read some parts of offeranswer draft and find
> something
> >> >>>>might be deserving discussion.
> >> >>>>
> >> >>>>//begin of text(part):
> >> >>>> For example, in Figure 1, only the SDP in F6 is the answer. The
> SDP
> >> >>>> in the non-reliable response (F2) is the preview of the answer
> and
> >> >>>> must be the same as the answer in F6. Receiving F2, the UAC
> should
> >> >>>> act as if it receives the answer.
> >> >>>>//end of text(part)
> >> >>>>
> >> >>>>[Gao] In fact, UAS sending SDP in non-reliable response is for
> potential
> >> >>>>early media usage. Considering some UAS may have different address
> for
> >> >>>>early media channel and the final session, some UAS may send
> different
> >> >>>>SDP(compare with the answer) in non-reliable response. And I really
> found
> >> >>>>such equipment inside and outside of ZTE. And considering UAC,
> Ithink we
> >> >>>>should allow the UAC ignore the SDP in non-reliable response, while
> some
> >> >>>>UAC really do not handle any SDP which is not offer or answer.
> >> >>>>
> >> >>>>But the permissibility of the degree of the difference might be
> delicate.
> >> >>>>If the non-answer SDP just has different ip address or port, it
> seams OK.
> >> >>>>If the non-answer SDP has different media streams, it would be hard
> to
> >> >>>>handle for UAC.
> >> >>>>
> >> >>>>
> >> >>>>And I re-read correlative part of RFC3261. I don't know that whether
> >> >>>>allowing different SDP(compare with the answer) in non-reliable
> response
> >> >>>>is violation/correction of current text or not.
> >> >>>>
> >> >>>>//correlative part of RFC3261
> >> >>>> o If the initial offer is in an INVITE, the answer MUST be in
> a
> >> >>>> reliable non-failure message from UAS back to UAC which is
> >> >>>> correlated to that INVITE. For this specification, that is
> >> >>>> only the final 2xx response to that INVITE. That same
> exact
> >> >>>> answer MAY also be placed in any provisional responses sent
> >> >>>> prior to the answer. The UAC MUST treat the first session
> >> >>>> description it receives as the answer, and MUST ignore any
> >> >>>> session descriptions in subsequent responses to the initial
> >> >>>> INVITE.
> >> >>>>
> >> >>>>Thanks,
> >> >>>>
> >> >>>>Gao
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email protected] for questions on current sip
> Use [email protected] for new developments of core SIP
>
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP