Re: AW: AW: [Sip] Extension of conference procedures

["Peili Xu" <[e-mail]>]

Yes, It's vague in RFC3261.  I'm only aware of the usage in REFER now.
It'll be good to clarify the semantics in the usage in url-list.

2007/9/5, DRAGE, Keith (Keith) <[e-mail]>:
> So this is a convenient way to bring us back to the other half of the issue which we do not seem to have discussed yet. When the syntax was defined that allowed ?headers:
>
>       Headers: Header fields to be included in a request constructed
>          from the URI.
>
>          Headers fields in the SIP request can be specified with the "?"
>          mechanism within a URI.  The header names and values are
>          encoded in ampersand separated hname = hvalue pairs.  The
>          special hname "body" indicates that the associated hvalue is
>          the message-body of the SIP request.
>
> What usage did the SIP WG envisage for this, and thus what semantics did they define for that usage.
>
> Is it appropriate to assign new semantics to such usage?
>
> Regards
>
> Keith
>
> > -----Original Message-----
> > From: Huelsemann, Martin [mailto:[e-mail]]
> > Sent: Wednesday, September 05, 2007 11:59 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: AW: AW: AW: [Sip] Extension of conference procedures
> >
> > Hi Eric,
> >
> > there is nothing new added to RFC 3261, only perhaps some new
> > semantics to subclause 19.1.1. The conference user would have
> > to know about this, but that's okay, there are always some
> > requirements if you want to use a service (REFER as default,
> > proposed "?" usage as fallback).
> >
> > What are the additions the user who's added to the conference
> > would have to support? The added user would receive basically
> > just a reINVITE, so in principal support of 3261 would be sufficient.
> >
> >
> > basically, in principal: the intention to minimize the
> > requirements on B for a service which A uses, in order to
> > maximize the chance this ad-hoc conference will work; perhaps
> > there will be no 100% guarantee for this.
> >
> >
> > BR, Martin
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Eric Burger [mailto:[e-mail]]
> > > Gesendet: Dienstag, 4. September 2007 20:00
> > > An: Hülsemann, Martin
> > > Cc: [e-mail]
> > > Betreff: Re: AW: AW: [Sip] Extension of conference procedures
> > >
> > >
> > > I must be missing an important point.  To me, right now, this whole
> > > thread, besides being 11 pages long, seems pointless.
> > >
> > > Either a phone knows about REFER or the phone does 3261.
> > > Adding something
> > > new to 3261 means the phone needs to know about it means it
> > might as
> > > well know about REFER.
> > >
> > > Hacking 3261 to enable a man-in-the-middle attack, where the
> > > conference server or PSAP can take over a call (good thing)
> > enables a
> > > nasty device to take over a call (bad thing) is not a good idea.
> > >
> > >
> > > On 8/30/07 4:37 AM, "Huelsemann, Martin"
> > <[e-mail]>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I think especially for the case where A has several ongoing
> > > dialogs with B and
> > > > A wants only to include a certain of the dialogs into the
> > > conference, he has
> > > > to give some information in which of the dialogs the AS
> > > shall start 3pcc
> > > > procedures.
> > > >
> > > >
> > > > Regards, Martin
> > > >
> > > >
> > > >
> > > >> -----Ursprüngliche Nachricht-----
> > > >> Von: Peili Xu [mailto:[e-mail]]
> > > >> Gesendet: Donnerstag, 30. August 2007 08:53
> > > >> An: 'Even, Roni'
> > > >> Cc: [e-mail]
> > > >> Betreff: RE: AW: [Sip] Extension of conference procedures
> > > >>
> > > >>
> > > >>
> > > >> Hi Roni,
> > > >>
> > > >> Your case is even "smarter" than mine ;-)  that's OK for me.
> > > >>
> > > >> But, I'm just wondering whether there is case that A has
> > multiple
> > > >> on going dialogs with say B, C, D and only want to turn
> > A-B and A-C
> > > >> to a conference then dialog information maybe needed.
> > > >>
> > > >> I'd happy to hear clarification for this point from whom
> > raise the
> > > >> requirements.
> > > >>
> > > >> Peili
> > > >>
> > > >> -----Original Message-----
> > > >> From: Even, Roni [mailto:[e-mail]]
> > > >> Sent: Thursday, August 30, 2007 2:09 PM
> > > >> To: Peili Xu
> > > >> Cc: [e-mail]
> > > >> Subject: RE: AW: [Sip] Extension of conference procedures
> > > >>
> > > >>
> > > >>
> > > >> Hi,
> > > >> I think you misunderstood what I menat by "smart". If there is a
> > > >> softyswitch acting as a 3PCC, it controls the dialogs and can
> > > >> redirect the media to the media server suppling the conference
> > > >> function.
> > > >> There is no need for A to give information about the dialog
> > > >>
> > > >> Roni Even
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Peili Xu [mailto:[e-mail]]
> > > >>> Sent: Wednesday, August 29, 2007 5:08 PM
> > > >>> To: Even, Roni
> > > >>> Cc: Huelsemann, Martin; [e-mail]
> > > >>> Subject: Re: AW: [Sip] Extension of conference
> > > >> procedures
> > > >>>
> > > >>> Hi Martin, Denis,
> > > >>>
> > > >>> I agree with Roni that you may need to decide who is
> > > >> "smart".
> > > >>>
> > > >>> I guess you want to simulate the 3PTY services in
> > > >> PSTN, A make call to
> > > >>> B, then A Hold B, then A Make Call to C, then A could
> > > >> do sth like hook
> > > >>> flash to turn the call between A-B and A-C to an 3pty
> > > >> conference.
> > > >>> later, A could still turn the conferece back to 2
> > > >> independant call.
> > > >>>
> > > >>> You have some assumption that the AS who performs
> > > >> conference is on the
> > > >>> path between A-B and A-C. And A could inform the AS to
> > > >> turn the call
> > > >>> between A-B and A-C to a conference.
> > > >>>
> > > >>> If the assumption is correct, what you want is just to
> > > >> tell the AS
> > > >>> which dialogs should be turned to conference by
> > > >> sending an INVITE with
> > > >>> the related dialog information.
> > > >>>
> > > >>> If the above understanding is correct, I'd agree with
> > > >> the initial
> > > >>> proposal from Denis.
> > > >>> Just to convey the dialog information along with the
> > > >> URI-List.
> > > >>>
> > > >>> Peili
> > > >>>
> > > >>>
> > > >>>
> > > >>> 2007/8/29, Even, Roni <[e-mail]>:
> > > >>>>
> > > >>>> Hi,
> > > >>>> In this case, like in PSTN the switch does it. You
> > > >> have to decide
> > > >>>> who is
> > > >>> "smart" the network or the end device.
> > > >>>> A "simple" RFC 3261 only phone relies on a 3PCC or
> > > >> softswitch to
> > > >>>> manage
> > > >>> telephony services (not only conferencing)
> > > >>>>
> > > >>>> Roni Even
> > > >>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: Huelsemann, Martin
> > > >> [mailto:[e-mail]]
> > > >>>>> Sent: Wednesday, August 29, 2007 1:05 PM
> > > >>>>> To: Even, Roni
> > > >>>>> Cc: [e-mail]; [e-mail]
> > > >>>>> Subject: AW: AW: [Sip] Extension of conference
> > > >> procedures
> > > >>>>>
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>> also for the scenario where A refers B to dial
> > > >> into a conference,
> > > >>>>> the problem is when B has a terminal not
> > > >> supporting REFER (or just
> > > >>>>> doesn't want to accept the REFER for some
> > > >> reasons), A cannot use
> > > >>>>> the
> > > >>> conference
> > > >>>>> service.
> > > >>>>>
> > > >>>>> Of course these simple terminals are not the
> > > >> desired use-case and
> > > >>> there
> > > >>>>> will be limitations. But if there is a possible
> > > >> fallback solution
> > > >>>>> that
> > > >>> at
> > > >>>>> least increases the chance that A can use the
> > > >> service despite the
> > > >>>>> fact that B does not fulfill all the requirements
> > > >> for the service,
> > > >>>>> I think
> > > >>> we
> > > >>>>> should try to figure it out.
> > > >>>>>
> > > >>>>> Regards, Martin
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> -----Ursprüngliche Nachricht-----
> > > >>>>>> Von: Even, Roni [mailto:[e-mail]]
> > > >>>>>> Gesendet: Montag, 27. August 2007 12:16
> > > >>>>>> An: Hülsemann, Martin; [e-mail]
> > > >>>>>> Cc: [e-mail]
> > > >>>>>> Betreff: RE: AW: [Sip] Extension of conference
> > > >> procedures
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Hi,
> > > >>>>>> My view is that every solution where you only
> > > >> have A, B and a
> > > >>>>>> conference server and B only supports RFC 3261
> > > >> will have some
> > > >>>>>> limitation and will be a hack.
> > > >>>>>>
> > > >>>>>> The recommended way to do it is for A to send a
> > > >> Refer to B to
> > > >>>>>> the focus.
> > > >>>>>>
> > > >>>>>> Also asking that B supporting only RFC 3261 will
> > > >> support
> > > >>>>>> conference event package is contradictory. B
> > > >> will not even be
> > > >>>>>> aware that it is in a conference.
> > > >>>>>>
> > > >>>>>> Roni Even
> > > >>>>>>
> > > >>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > > >>>>>> A consensus means that everyone agrees to say
> > > >> collectively what
> > > >>>>>> no one believes individually
> > > >> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > > >>>>>>
> > > >>>>>>> -----Original Message-----
> > > >>>>>>> From: Huelsemann, Martin
> > > >> [mailto:[e-mail]]
> > > >>>>>>> Sent: Monday, August 27, 2007 12:59 PM
> > > >>>>>>> To: [e-mail]
> > > >>>>>>> Cc: [e-mail]
> > > >>>>>>> Subject: AW: AW: [Sip] Extension of conference
> > > >> procedures
> > > >>>>>>>
> > > >>>>>>> Hi,
> > > >>>>>>>
> > > >>>>>>> the pure RFC 3261 client won't be the normal
> > > >> case, of
> > > >>>>>> course. But there
> > > >>>>>>> might be networks with which you want to
> > > >> interwork where
> > > >>>>>> those simple
> > > >>>>>>> clients are existing.
> > > >>>>>>> Okay, you got me, it's again the PSTN
> > > >> interworking. So
> > > >>>>>> let's say what is
> > > >>>>>>> needed is a fallback solution for this case.
> > > >>>>>>> On the other hand, this fallback might be
> > > >> useful for a
> > > >>>>>> normal SIP client
> > > >>>>>>> which supports RFC3891, too, e.g. if there are
> > > >> problems with
> > > >>>>>>> authorization.
> > > >>>>>>>
> > > >>>>>>> The user experience of the invitee should be
> > > >> exactly as you
> > > >>>>>> describe.
> > > >>>>>>>
> > > >>>>>>> If A sends the reINVITE / UPDATE himself that
> > > >> could be a
> > > >>>>>> solution, too.
> > > >>>>>>> The only thing is, can B then use all the
> > > >> conference features (e.
> > > >>> g.
> > > >>>>>>> conference event package), when the focus has
> > > >> no knowledge on
> > > >>>>>>> the signalling level that B is connected to
> > > >> the conference bridge?
> > > >>>>>>>
> > > >>>>>>> Regards, Martin
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> -----Ursprüngliche Nachricht-----
> > > >>>>>>>> Von: Jeroen van Bemmel
> > > >> [mailto:[e-mail]]
> > > >>>>>>>> Gesendet: Sonntag, 26. August 2007 15:24
> > > >>>>>>>> An: Hülsemann, Martin
> > > >>>>>>>> Cc: Alexeitsev, Denis; [e-mail]
> > > >>>>>>>> Betreff: Re: AW: [Sip] Extension of
> > > >> conference procedures
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Martin,
> > > >>>>>>>>
> > > >>>>>>>> Now it becomes more clear. So the
> > > >> requirement is to
> > > >>>>>> enable a scenario
> > > >>>>>>>> where a regular call is transformed into a
> > > >> conference
> > > >>>>>> call, assuming
> > > >>>>>>>> that the invitee only has a "pure RFC3261"
> > > >> client.
> > > >>>>>>>> More specifically:
> > > >>>>>>>>
> > > >>>>>>>> - to get a smooth user experience, the
> > > >> scenario must not
> > > >>>>>>>> cause
> > > >>> the
> > > >>>>>>>> invitee's phone to ring, and/or ask the
> > > >> invitee for
> > > >>>>>>>> permission (acceptance is assumed to be
> > > >> implied)
> > > >>>>>>>>
> > > >>>>>>>> What if A would send the reINVITE (or
> > > >> UPDATE) itself, while
> > > >>>>>>>> filling in the SDP according to the media
> > > >> provided by the
> > > >>>>>>>> conference server (i.e.
> > > >>>>>>>> use codecs, media ports as received from the
> > > >> focus)? (trying
> > > >>>>>>>> to get the requirements more clear here)
> > > >>>>>>>>
> > > >>>>>>>> In practice, it may still be a challenge to
> > > >> get such "very
> > > >>> simple
> > > >>>>>>>> terminals" to properly handle a change of
> > > >> media (i.e. new
> > > >>>>>> destination
> > > >>>>>>>> ip/port for sending, new source ip/port and
> > > >> RTP src id,
> > > >>>>>> and possibly
> > > >>>>>>>> different codecs)
> > > >>>>>>>>
> > > >>>>>>>> Regards,
> > > >>>>>>>> Jeroen
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Huelsemann, Martin wrote:
> > > >>>>>>>>> Hi Jeroen,
> > > >>>>>>>>>
> > > >>>>>>>>> the usage of the Replaces header is of
> > > >> course the best
> > > >>>>>>>> solution, it's also described in the
> > > >> regarding 3GPP
> > > >>>>>>>> conferencing spec.
> > > >>>>>>>>> The disadvantage of the usage of the
> > > >> Repaces header is,
> > > >>>>>>>> that it puts requirements on the UE of the
> > > >> invited user, it
> > > >>>>>>>> would have to support RFC 3891. And if it
> > > >> supports, it
> > > >>>>>>>> really would have to accept the 2nd INVITE,
> > > >> which is not
> > > >>>>>>>> mandatory according to RFC 3891 I think.
> > > >>>>>>>>> Anyway what is needed in addition is a
> > > >> solution how also
> > > >>>>>>>> very simple terminals (e. g. only supporting
> > > >> RFC 3261) can
> > > >>>>>>>> be invited to an ad-hoc conference, whithout
> > > >> having to say
> > > >>>>>>>> to the invited user to please hang up
> > > >> because there will be
> > > >>>>>>>> a call from the focus shortly.
> > > >>>>>>>>>
> > > >>>>>>>>> Re-using an already established dialog at
> > > >> least at the
> > > >>>>>>>> first glance seems to be a simply and
> > > >> invited UE independent
> > > >>>>>>>> solution. And as this re-INVITE it wanted by
> > > >> at least one of
> > > >>>>>>>> the involved user, I would more compare it
> > > >> to some kind of
> > > >>>>>>>> triggered 3rd party call control than to
> > > >> spoofing.
> > > >>>>>>>>>
> > > >>>>>>>>> Of course as you said it would have to be
> > > >> made clear that
> > > >>>>>>>> the focus is able to collect all the
> > > >> information needed for
> > > >>>>>>>> sending re-INVITEs (proposed "?" mechanism
> > > >> usage, dialog
> > > >>>>>>>> event package, etc.).
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Regards, Martin
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> -----Ursprüngliche Nachricht-----
> > > >>>>>>>>>> Von: Jeroen van Bemmel
> > > >> [mailto:[e-mail]]
> > > >>>>>>>>>> Gesendet: Freitag, 24. August 2007 17:06
> > > >>>>>>>>>> An: Alexeitsev, Denis; [e-mail]
> > > >>>>>>>>>> Betreff: Re: [Sip] Extension of
> > > >> conference procedures
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Denis,
> > > >>>>>>>>>>
> > > >>>>>>>>>> If I understand your scenario, "focus" is
> > > >> a third party
> > > >>>>>>>>>> separate from A and B, right? (e.g. a
> > > >> conference server)
> > > >>>>>>>>>>
> > > >>>>>>>>>> In that case the focus is not a party in
> > > >> the A-B dialog,
> > > >>>>>>>>>> and would need more than Call-ID, From
> > > >> and To to be able
> > > >>>>>>>>>> to construct a reINVITE that B would
> > > >> accept as coming
> > > >>>>>>>>>> from A (e.g. CSeq). In any case, this
> > > >> looks like a very
> > > >>>>>>>>>> inelegant, hacked solution (as the
> > > >> conference server is
> > > >>>>>>>>>> basically spoofing)
> > > >>>>>>>>>>
> > > >>>>>>>>>> RFC4579 section 5.10 provides some
> > > >> insipration, as well
> > > >>>>>>>>>> as
> > > >>>>>>>>>>
> > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-
> > > >>> service
> > > >>>>>>>>>> -examples-13.txt
> > > >>>>>>>>>> scenario 2.5
> > > >>>>>>>>>>
> > > >>>>>>>>>> For example, A could include a 'Replaces'
> > > >> header in the
> > > >>>>>>>>>> URI it includes in its conference URI
> > > >> list. Then the
> > > >>>>>>>>>> conference server would
> > > >>>>>>>> send a new
> > > >>>>>>>>>> (out-of-dialog) INVITE to B containing
> > > >> this Replaces
> > > >>>>>>>>>> header, and B would know that it is
> > > >> associated with the
> > > >>>>>>>>>> dialog it has with A (and can replace it,
> > > >> without ringing
> > > >>>>>>>>>> if the UA is constructed like that)
> > > >>>>>>>>>>
> > > >>>>>>>>>> The conference server should probably
> > > >> also include a
> > > >>>>>>>>>> Referred-By containing A's AoR, either
> > > >> automatically
> > > >>>>>>>>>> (i.e. copy from From header in
> > > >>>>>>>>>> INVITE) or
> > > >>>>>>>>>> included by A in the URI (former is
> > > >> better)
> > > >>>>>>>>>>
> > > >>>>>>>>>> Regards,
> > > >>>>>>>>>> Jeroen
> > > >>>>>>>>>>
> > > >>>>>>>>>> Alexeitsev, D wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> I'd like to discuss the extension of the
> > > >> current
> > > >>>>>>>>>>> conference
> > > >>>>>>>>>>>
> > > >>>>>>>>>> procedures
> > > >>>>>>>>>>
> > > >>>>>>>>>>> with the following functionality.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 3GPP conference specifications are
> > > >> basing generally on
> > > >>>>>>>>>>> the Conferencing Framework (RFC 4353)
> > > >> and for one
> > > >>>>>>>>>>> possibility
> > > >>>>>>>>>>>
> > > >>>>>>>>>> of inviting
> > > >>>>>>>>>>
> > > >>>>>>>>>>> users to the confrence on
> > > >>>>>> draft-ietf-sip-uri-list-conferencing.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Using the conferencing framework, the
> > > >> following
> > > >>>>>>>>>>> situation
> > > >>>>>>>> can occur
> > > >>>>>>>>>>> when a user is invited to an ad-hoc
> > > >> conference:
> > > >>>>>>>>>>> User A is in a dialog with user B, and
> > > >> decides to start
> > > >>>>>>>>>>> a
> > > >>>>>>>>>>>
> > > >>>>>>>>>> conference,
> > > >>>>>>>>>>
> > > >>>>>>>>>>> for example using an INVITE request to
> > > >> the focus which
> > > >>>>>>>>>>>
> > > >>>>>>>>>> includes a URI
> > > >>>>>>>>>>
> > > >>>>>>>>>>> list with the URIs of the users which
> > > >> shall be added to
> > > >>>>>>>>>>> the conference, incl. B. So when the
> > > >> INVITE request from
> > > >>>>>>>>>>> the
> > > >>> focus
> > > >>>>>>>>>>> arrives at B, he is still in the
> > > >> original dialog with
> > > >>>>>> A, and so it
> > > >>>>>>>>>>> depends on B if he accepts the 2nd
> > > >> INVITE and the
> > > >>>>>>>> conference can be
> > > >>>>>>>>>>> established.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> At the last 3GPP CT1 meeting the idea of
> > > >> transporting
> > > >>>>>>>>>>> dialog identifiers together with the
> > > >> URIs was introduced
> > > >>>>>>>>>>> to
> > > >>>>>> solve this
> > > >>>>>>>>>>> problem. Basing on the idea that the
> > > >> procedures at
> > > >>>>>> the conference
> > > >>>>>>>>>>> server are extended in that way, that
> > > >> the conference
> > > >>>>>>>> server is aware
> > > >>>>>>>>>>> of already established dialogs, the
> > > >> focus then has the
> > > >>>>>>>>>>>
> > > >>>>>>>>>> possibility to
> > > >>>>>>>>>>
> > > >>>>>>>>>>> send re-INVITES in the indicated dialogs
> > > >> and connect the
> > > >>>>>>>> media from
> > > >>>>>>>>>>> the invited users to the conference
> > > >> bridge.
> > > >>>>>>>>>>> In the URI list the dialogs can be
> > > >> indicated using the
> > > >>>>>>>> "?" mechanism
> > > >>>>>>>>>>> according to subclause 19.1.1 of RFC
> > > >> 3261.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Following example shows the proposed
> > > >> mechanism:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> INVITE Conference
> > > >>>>>>>>>>> To: Conference
> > > >>>>>>>>>>> From: A
> > > >>>>>>>>>>> Require: recipient-list-invite
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Content-Type:
> > > >> application/resource-lists+xml
> > > >>>>>>>>>>> Content-Disposition: recipient-list
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
> > > >> <resource-lists
> > > >>>>>>>>>>> xmlns="urn:ietf:params:xml:ns:resource-
> > > >>> lists"
> > > >>>>>>>>>>>
> > > >> xmlns:cp="urn:ietf:params:xml:ns:copyControl">
> > > >>>>>>>>>>>   <list>
> > > >>>>>>>>>>>    <entry
> > > >> uri="B?Call-ID=1&From=A%3Btag%3Da&To=B%3Btag%3Db"
> > > >>>>>>>>>>> cp:copyControl="to"/>
> > > >>>>>>>>>>>    <entry
> > > >> uri="C?Call-ID=2&From=A%3Btag%3Da&To=C%3btag%3Dc"
> > > >>>>>>>>>>> cp:copyControl="to"/>
> > > >>>>>>>>>>>   </list>
> > > >>>>>>>>>>>  </resource-lists>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Greetings,
> > > >>>>>>>>>>> Denis Alexeitsev
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >> _______________________________________________
> > > >>>>>>>>>>> Sip mailing list
> > > >>>>>>>>>>>
> > > >> https://www1.ietf.org/mailman/listinfo/sip
> > > >>>>>>>>>>> This list is for NEW development of the
> > > >> core SIP
> > > >>>>>>>>>>> Protocol Use
> > > >> [e-mail] for
> > > >>>>>>>>>>> questions on
> > > >>>>>> current sip
> > > >>>>>>>>>>> Use [e-mail] for new
> > > >> developments on the
> > > >>>>>>>> application of sip
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >> _______________________________________________
> > > >>>>>>>>>> Sip mailing list
> > > >>>>>>>>>>
> > > >> https://www1.ietf.org/mailman/listinfo/sip
> > > >>>>>>>>>> This list is for NEW development of the
> > > >> core SIP Protocol
> > > >>>>>>>>>> Use [e-mail] for
> > > >> questions on
> > > >>>>>> current sip
> > > >>>>>>>>>> Use [e-mail] for new developments
> > > >> on the
> > > >>>>>> application of sip
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >> _______________________________________________
> > > >>>>>>> Sip mailing list
> > > >> https://www1.ietf.org/mailman/listinfo/sip
> > > >>>>>>> This list is for NEW development of the core
> > > >> SIP Protocol Use
> > > >>>>>>> [e-mail] for questions
> > > >> on current sip
> > > >>>>>>> Use [e-mail] for new developments on
> > > >> the application
> > > >>>>>>> of
> > > >>> sip
> > > >>>>>>
> > > >>>>
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> Sip mailing list
> > > >> https://www1.ietf.org/mailman/listinfo/sip
> > > >>>> This list is for NEW development of the core SIP
> > > >> Protocol Use
> > > >>>> [e-mail] for questions on
> > > >> current sip Use
> > > >>>> [e-mail] for new developments on the
> > > >> application of sip
> > > >>>>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Sip mailing list
> > > >> https://www1.ietf.org/mailman/listinfo/sip
> > > >> This list is for NEW development of the core SIP Protocol Use
> > > >> [e-mail] for questions on
> > current sip Use
> > > >> [e-mail] for new developments on the application of sip
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > >> This list is for NEW development of the core SIP Protocol Use
> > > >> [e-mail] for questions on
> > current sip Use
> > > >> [e-mail] for new developments on the application of sip
> > > >>
> > > >
> > > >
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol Use
> > > > [e-mail] for questions on current sip Use
> > > > [e-mail] for new developments on the application of sip
> > >
> > >
> > > Notice:  This email message, together with any attachments, may
> > > contain information  of  BEA Systems,  Inc.,  its
> > subsidiaries  and
> > > affiliated entities,  that may be confidential,  proprietary,
> > > copyrighted  and/or legally privileged, and is intended
> > solely for the
> > > use of the individual or entity named in this message. If
> > you are not
> > > the intended recipient, and have received this message in error,
> > > please immediately return this by email and then delete it.
> > >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > [e-mail] for questions on current sip
> > Use [e-mail] for new developments on the application of sip
> >
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip