Re: About offeranswer draft:
Eric wang <[email protected]> Fri, 16 Apr 2010 11:32:24 +0800
| Newsgroups | gmane.ietf.sipping |
|---|---|
| Message-ID | <[email protected]> |
HI Christer
inlines
2010/4/16 Christer Holmberg <[email protected]>
> Hi,
>
> SIP used to be (m)music to my ears...
>
> Anyway, I don't anyone has said that it is "forbidden" for a UAC to use a
> SDP in an unreliable 18x. But, it is not the "official" SDP answer.
>
> And, if the UAC uses the SDP in the unreliable 18x, and the SDP in the
> reliable answer is then different, the UAC should consider it as a protocol
> error in my opinion - not do any "switching".
>
I think UAC should consider SDP in reliable response as the correct one and
listen to it.
I don't konw why unreliable 18x with SDP be considered as answer if
received, I will be appreciate if someone tell my why.It seems like for
purpose as precondition, if I'm right, I recommand use reliable 18x with SDP
for precondition and treat SDP in reliable response as answer that should be
used finally(I konw it's violate rfc3261).
>
> >We shouldn't make complicated rules because the system has already been
> complicated.
>
> What is complicated in "There can be only one SDP answer per transaction,
> and it comes in the first reliable response of that transaction"?
I mean, It's complicated if SDPs in reliable responses should be
ingored(treated as neither offer nor answer), because UAC has already
received answer SDP in either reliable or unreliable response.
I support no SDP in reliable responses should be ignored, we should trust
*reliable*.
> >In my opinion, the offer/answer model works well if responses are
> reliable.
> >If we allow several reliable 18x with SDP, what happen if 18x is after
> UPDATEs.There must be some rules >saying "NO".I prefer several reliable 18xs
> with SDP appear only in fork.
>
> If the UAC sends a new offer in UPDATE, it will receive the new answer in
> the UPDATE 200 OK.
>
>
Yes!
> The 18x still belongs to the INVITE transaction, and may contain the
> previous SDP answer. But, since you have already received an SDP answer for
> the INVITE transaction, the SDP in the new 18x it has no meaning - no matter
> if there are UPDATE(s) or not...
>
>
The meaningless SDP would make mechanism harder to implementation.
BR,
Eric
> Regards,
>
> Christer
>
>
>
>
>
>
> 在 2010年4月14日 下午10:02，Paul Kyzivat <[email protected]<mailto:
> [email protected]>>写道：
>
>
> Eric wang wrote:
> > 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.
>
> IMO this makes no sense. For one thing, the UAC is instructed to accept
> the first and ignore the rest, so sending differing values will have no
> utility. For another, this only affects where the UAS will receive media
> - it can have no effect on where the UAC receives media. Generally the
> UAC isn't transmitting until the call is established, so what is the point.
>
> > But, when I saw the chart below, the only words in my mind is ,"OMG,
> > the SIP is never SI(m)P(le) again!"
>
> Where have you been? SIP hasn't been simple since early in the century.
>
> Thanks,
> Paul
>
>
> > 2010/4/14 OKUMURA Shinji <[email protected]<mailto:
> [email protected]>
> > <mailto:[email protected]<mailto:[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]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[email protected]>>
> > Mon, 12 Apr 2010 11:37:09 +0800
> > >Hi Shinji,
> > >
> > >Please see inlines.
> > >
> > >Thanks,
> > >
> > >Gao
> > >
> > >[email protected]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[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]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[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]<mailto:
> [email protected]>
> > <mailto:[email protected]<mailto:
> [email protected]>>>
> > >> >发件人: [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> > >> >2010-04-09 16:30
> > >> >
> > >> >收件人
> > >> >[email protected]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[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]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[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]<mailto:
> [email protected]>
> > <mailto:[email protected]<mailto:
> [email protected]>>>
> > >> >>发件人: [email protected]<mailto:[email protected]
> >
> > <mailto:[email protected]<mailto:[email protected]>>
> > >> >>2010-04-09 14:23
> > >> >>
> > >> >>收件人
> > >> >>[email protected]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[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]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[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]<mailto:
> [email protected]>
> > <mailto:[email protected]<mailto:
> [email protected]>>>
> > >> >>>发件人: [email protected]<mailto:
> [email protected]>
> > <mailto:[email protected]<mailto:[email protected]>>
> > >> >>>2010-04-09 10:13
> > >> >>>
> > >> >>>收件人
> > >> >>>[email protected]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[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]<mailto:[email protected]> <mailto:
> [email protected]<mailto:[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]<mailto:
> [email protected]>
> > <mailto:[email protected]<mailto:
> [email protected]>> for questions on current sip
> > Use [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:
> [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]<mailto:
> [email protected]> for questions on current sip
> > Use [email protected]<mailto:[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