Too many messages - it would be insane to reply to them all. This reply is generally to several of Eric's prior messages in this thread and the discussion about them. IIUC, eric doesn't like SDP in unreliable responses. But such usage is still very common. There are many deployments that don't use PRACK at all. So implementations must be prepared for this. When reliable provisionals are *not* used, providing "a preview" (my terminology for this) in unreliable provisionals is very valuable, because it allows the media streams to get started sooner than if the UAC had to wait for the 200. So the UAC has much incentive to honor the SDP in an unreliable provisional in order to get the media going. (The 3261 text says the UAC MUST honor the SDP in the reliable provisional if it receives it. But if it chose not to honor it, it could simply claim that it was lost somewhere along the way, maybe after the network interface on its box. And who can argue?) Even when the UAC has included Supported:100_rel in the INVITE, there is no guarantee that the UAS supports it, or is willing to use it. So still in this case the UAC has strong motivation to honor the SDP in an unreliable provisional. Support for reliable provisionals has to be consistent with all of the above. It provides *additional* behavior options - it removes none of the above. (Unless the UAC specifies Required:100_rel. Lets not talk about that case now.) A nicely behaved UAS that is intending to use reliable provisionals will probably not ever send an unreliable provisional containing SDP. In that case Eric will be happy. But that is not *required* behavior. Maybe it should have been, but since it was not, it would now be harder to go back and fix than it is to simply cope with it. So we carefully specify what is meant if SDP is received in an unreliable provisional and then again in a reliable provisional. That's my take on this particular discussion. Thanks, Paul Eric wang wrote: > HI Christer , > > > > > 2010/4/16 Christer Holmberg <christer.holmberg@xxxxxxxxxxxx > <mailto:christer.holmberg@xxxxxxxxxxxx>> > > > 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. > > Yes, and I think that is what at least me and Paul have been trying > to say. But, after you've received the answer in one reliable > answer, it can't be updated in another reliable answer. > > > Eric: Agree. And It's better another reliable answer doesn't exist. > > > > > >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 will NOT be considered as answer. Sometimes we talk about it as a > "preview of the answer". Whatever the UAC does with it is > unspecified (unless you use ICE, where the unreliable SDP actually > IS used - but it is still not considered as answer). > > > Eric: If it is a "preview of the answer", I think the negotiation should > be like precondition, not SDP in unreliable response. > I prefer the SDP in unreliable response can used for something else, eg, > the CALLED want to send CALLER a music while alerting. > > > > > > >>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*. > > I agree. > > But, still, according to the rules the SDPs in the unreliable and > reliable responses have to be the same. > > > Eric: I'd be glad if you can explain why they should be the same. > > > > > > >>>>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. > > I don't understand how it would make anything harder. Once you've > received an SDP answer in a reliable response, you simply don't care > about the SDPs in the additional responses... > > > Eric: I meant harder, not cannot:) > If meaningless SDPs are allowed, as a B2BUA server, we > should distinguish the meaning SDP from meaningless, should recognize if > the SDP in reliable 18x is a new offer, when this happened in a > complex service such as Call Transfer, meaningless SDPs will make the > implementation more complex. > > > > > Maybe we can recommend that, once the UAS has sent the SDP answer in > a reliable response, it should not include it in additional > responses for the same transaction. But, the UAC still has to be > able to handle cases where the additional responses do contain SDP. > > > Eric: I suppose so. Then the UAC may just return an error to UAS, I think. > > BR > Eric > > > > > > > > 在 2010年4月14日 下午10:02，Paul Kyzivat > <pkyzivat@xxxxxxxxx > <mailto:pkyzivat@xxxxxxxxx><mailto:pkyzivat@xxxxxxxxx > <mailto:pkyzivat@xxxxxxxxx>>>写道： > > > > 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 <shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx><mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx>> > > > <mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx><mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx>>>> > > > > > 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 > > > > > gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>> <mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>>> > > > Mon, 12 Apr 2010 11:37:09 +0800 > > >Hi Shinji, > > > > > >Please see inlines. > > > > > >Thanks, > > > > > >Gao > > > > > > >sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx><mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx>> <mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx><mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx>>> 写于 > > > 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 > > >> > > > >> gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>> <mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>>> > > > >> 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 <shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx><mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx>> > > > <mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx><mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx>>>> > > >> >发件人: sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx><mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx>> <mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx><mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx>>> > > > >> >2010-04-09 16:30 > > >> > > > >> >收件人 > > > >> >sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx><mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx>> <mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx><mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx>>> > > > >> >抄送 > > >> > > > >> >主题 > > >> >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 > > >> > > > > >> >gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>> <mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>>> > > > >> >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 <shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx><mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx>> > > > <mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx><mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx>>>> > > > >> >>发件人: sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx><mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx>> > > > <mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx><mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx>>> > > > >> >>2010-04-09 14:23 > > >> >> > > >> >>收件人 > > > >> >>sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx><mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx>> <mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx><mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx>>> > > > >> >>抄送 > > >> >> > > >> >>主题 > > >> >>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 > > >> >> > > > >> >>gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>> <mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>>> > > > >> >>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 <shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx><mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx>> > > > <mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx><mailto:shinji.okumura@xxxxxxxxxxxx > <mailto:shinji.okumura@xxxxxxxxxxxx>>>> > > > >> >>>发件人: sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx><mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx>> > > > <mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx><mailto:sipping-bounces@xxxxxxxx > <mailto:sipping-bounces@xxxxxxxx>>> > > > >> >>>2010-04-09 10:13 > > >> >>> > > >> >>>收件人 > > > >> >>>sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx><mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx>> <mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx><mailto:sipping@xxxxxxxx > <mailto:sipping@xxxxxxxx>>> > > > >> >>>抄送 > > >> >>> > > >> >>>主题 > > >> >>>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 > > >> >>> > > > >> >>>gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>> <mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx><mailto:gao.yang2@xxxxxxxxxx > <mailto:gao.yang2@xxxxxxxxxx>>> > > > >> >>>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 sip-implementors@xxxxxxxxxxxxxxx > <mailto:sip-implementors@xxxxxxxxxxxxxxx><mailto:sip-implementors@xxxxxxxxxxxxxxx > <mailto:sip-implementors@xxxxxxxxxxxxxxx>> > > > <mailto:sip-implementors@xxxxxxxxxxxxxxx > <mailto:sip-implementors@xxxxxxxxxxxxxxx><mailto:sip-implementors@xxxxxxxxxxxxxxx > <mailto:sip-implementors@xxxxxxxxxxxxxxx>>> for questions on current sip > > Use sip@xxxxxxxx > <mailto:sip@xxxxxxxx><mailto:sip@xxxxxxxx <mailto:sip@xxxxxxxx>> > <mailto:sip@xxxxxxxx <mailto:sip@xxxxxxxx><mailto:sip@xxxxxxxx > <mailto:sip@xxxxxxxx>>> 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 sip-implementors@xxxxxxxxxxxxxxx > <mailto:sip-implementors@xxxxxxxxxxxxxxx><mailto:sip-implementors@xxxxxxxxxxxxxxx > <mailto:sip-implementors@xxxxxxxxxxxxxxx>> for questions on current sip > > > Use sip@xxxxxxxx > <mailto:sip@xxxxxxxx><mailto:sip@xxxxxxxx <mailto:sip@xxxxxxxx>> 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
