Internet-Drafts | 1 Jul 2002 12:39
Picon
Favicon

I-D ACTION:draft-ietf-sip-message-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-sip-message-05.txt
	Pages		: 22
	Date		: 28-Jun-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.
(Continue reading)

Alexeitsev, D | 1 Jul 2002 13:17
Picon

Re: Local vs Remote ringback on 180

Hello All,

Some comments/questions inline

Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Christer Holmberg [mailto:christer.holmberg <at> lmf.ericsson.se]
Gesendet am: Freitag, 28. Juni 2002 18:53
An: Chris Hogg
Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson; sip <at> ietf.org;
Bob Penfield
Betreff: Re: [Sip] Local vs Remote ringback on 180

[CHH] The UAS may still send early media, but since it sends 180 without
SDP it allows the UAC to generate local ringback tone, so the UAC now
can assume that it can "cut" the early media from the caller during that
time. If the UAS does NOT want the UAC to generate local ringback, the
180 would also contain SDP (the same SDP which was used in the 183 to
establish the early dialog, ie the SDP is not a new offer/answer -
simply a ringback "indicator").

[DA]I have a question about the need to receive the SDP in any responses in order to play remote ringback. As
the offer/answer draft says:
"Once the offerer has sent the offer, it MUST be prepared to receive media"

The SDP coming from the other side is used to send the media, that is unimportant in the ringback case. Am I
missing something here?

(Continue reading)

Christer Holmberg | 1 Jul 2002 13:26
Picon
Picon

Re: Local vs Remote ringback on 180


Hi,

"Alexeitsev, D" wrote:

> Hello All,
>
> Some comments/questions inline
>
> Greetings,
> Denis Alexeitsev
>
> -----Ursprüngliche Nachricht-----
> Von: Christer Holmberg [mailto:christer.holmberg <at> lmf.ericsson.se]
> Gesendet am: Freitag, 28. Juni 2002 18:53
> An: Chris Hogg
> Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson; sip <at> ietf.org;
> Bob Penfield
> Betreff: Re: [Sip] Local vs Remote ringback on 180
>
> [CHH] The UAS may still send early media, but since it sends 180 without
> SDP it allows the UAC to generate local ringback tone, so the UAC now
> can assume that it can "cut" the early media from the caller during that
> time. If the UAS does NOT want the UAC to generate local ringback, the
> 180 would also contain SDP (the same SDP which was used in the 183 to
> establish the early dialog, ie the SDP is not a new offer/answer -
> simply a ringback "indicator").
>
> [DA]I have a question about the need to receive the SDP in any responses in order to play remote ringback. As
the offer/answer draft says:
(Continue reading)

Mark Watson | 1 Jul 2002 15:35

RE: Local vs Remote ringback on 180

All,

I'm confused by this discussion, because there seems to be a desire to extrapolate some semantics about the *media* from a message which does not contain SDP. Apologies if I have missed the issue at hand, or if the following is obvious, but...

The unify model means that media and session state are completely independent, so, to talk about '180 with SDP' or '180 without SDP' makes no sense.

You can talk about the effect 180 has on the session state (indicates that called party is being alerted), but this has nothing to do with the media state (if there was media before, there still is, if there was no media before, there still isn't).

You can talk about the effect that SDP offer/answer exchanges have on the media, but this operates independently of the SIP message those SDP bodies arrive in.

So,

1) the UAC knows whether there is media or not (based on SDP offer/answer exchanges so far)
2) if 180 has been received, the UAC knows that the called party is alerting

If the UAC knows that the called party is alerting AND knows that there is media, it is a local matter what to do. Personally, I cannot see an argument for doing anything other than playing the media (it might contain 'ringing with call waiting announcement').

A PROBLEM arises if there is a UAS which negotiates media but then sends silence (no packets) - there ARE some reasons why it might want to do this to do with reducing clipping on answer. The result is that silence would be all the caller would hear even though the UAC may know that the called party is being alerted. I think we just have to say that it is foolish for the UAS to negotiate media and then send silence - it should put the media on hold if it has nothing to send.

Regards,

Mark

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg <at> lmf.ericsson.se]
> Sent: 01 July 2002 12:26
> To: Alexeitsev, D
> Cc: sip <at> ietf.org; Hogg, Chris [MOP:MA01:EXCH]
> Subject: Re: [Sip] Local vs Remote ringback on 180
>
>
>
> Hi,
>
> "Alexeitsev, D" wrote:
>
> > Hello All,
> >
> > Some comments/questions inline
> >
> > Greetings,
> > Denis Alexeitsev
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Christer Holmberg [mailto:christer.holmberg <at> lmf.ericsson.se]
> > Gesendet am: Freitag, 28. Juni 2002 18:53
> > An: Chris Hogg
> > Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson;
> sip <at> ietf.org;
> > Bob Penfield
> > Betreff: Re: [Sip] Local vs Remote ringback on 180
> >
> > [CHH] The UAS may still send early media, but since it
> sends 180 without
> > SDP it allows the UAC to generate local ringback tone, so
> the UAC now
> > can assume that it can "cut" the early media from the
> caller during that
> > time. If the UAS does NOT want the UAC to generate local
> ringback, the
> > 180 would also contain SDP (the same SDP which was used in
> the 183 to
> > establish the early dialog, ie the SDP is not a new offer/answer -
> > simply a ringback "indicator").
> >
> > [DA]I have a question about the need to receive the SDP in
> any responses in order to play remote ringback. As the
> offer/answer draft says:
> > "Once the offerer has sent the offer, it MUST be prepared
> to receive media"
> >
> > The SDP coming from the other side is used to send the
> media, that is unimportant in the ringback case. Am I missing
> something here?
>
> [CHH] For the specific ringback tone case one can argue that
> an SDP is not needed for the media itself (unless you need it
> for RTCP purpose,
> or something).
>
> However, there is no specific "remote ringback session" in
> SIP. You establish a generic early dialiog, by sending an
> offer and receiving an
> answer, which can then be used for any kind of early media
> (ringback tone, announcement,...), in any direction
> (depending on the "direction"
> indicators - sendrecv, sendonly, inactive etc etc).
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org for new developments on the application of sip
>

Salva Rey | 1 Jul 2002 11:23
Picon
Favicon

Forking proxy


Hi all,

a doubt regarding forking proxies,

why would a proxy do if forked an INVITE request, it got back some reliable 
provisional responses that established some early dialogs at the UAC, and 
then one of the UAS's sends a final response 200 oK. If the other early 
dialogs try to send further reliable provisional responses this wont get 
through the proxy since a final response was already sent on the response 
context. Should the proxy behaviour not only forward immediately 200ok 
responses to INVITE, but also reliable responses ?

best regards
Salva

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Christer Holmberg | 1 Jul 2002 16:45
Picon
Picon

Re: Local vs Remote ringback on 180


Hi Mark,

> I'm confused by this discussion, because there seems to be a desire to
> extrapolate some semantics about the *media* from a message which does
> not contain SDP. Apologies if I have missed the issue at hand, or if
> the following is obvious, but...
>
> The unify model means that media and session state are completely
> independent, so, to talk about '180 with SDP' or '180 without SDP'
> makes no sense.

I agree, but those are the terms used by the drafts I've refered to. The
ISUP/SIP mapping draft says that "180 with SDP" means that a remote
ringback will be generated, and bis-09 says that "180 without SDP" MAY
cause the UAC to generate a local ringback.

Of course, those statements may sometimes be valid, if we receive either
a 180 without SDP, OR we receive 180 with SDP - and no early dialog
still exists. My orignial question was what we do if we receive 180
without SDP, but we DO have an early dialog established. It has been
argued that the UAC should not generate local ringback in that case -
instead assume the UAS does it since there is an early dialog
established (if the UAS wants the UAC to generate local ringback it
would have to put the media on hold using UPDATE). IF that's the case, I
think it should me more clarified. Clarification is the only thing I've
asked for - no changes in the protocol.

> You can talk about the effect 180 has on the session state (indicates
> that called party is being alerted), but this has nothing to do with
> the media state (if there was media before, there still is, if there
> was no media before, there still isn't).

I've said all the time that the session state is not affected, only that
the 180 affects what the application does with the media.

So, what you just wrote means, that in the case we have an established
early dialog it really doesn't matter, from a ringback point of view, if
there is a SDP in the 180 or not. Is that the "official" clarification
I've asked for? :)

> You can talk about the effect that SDP offer/answer exchanges have on
> the media, but this operates independently of the SIP message those
> SDP bodies arrive in.

True. That is why I also asked if the SDP is a good "ringback indicator"
in the first place...

> So,
>
> 1) the UAC knows whether there is media or not (based on SDP
> offer/answer exchanges so far)
> 2) if 180 has been received, the UAC knows that the called party is
> alerting
>
> If the UAC knows that the called party is alerting AND knows that
> there is media, it is a local matter what to do. Personally, I cannot
> see an argument for doing anything other than playing the media (it
> might contain 'ringing with call waiting announcement').

I think it was earlier said that the decission can't be based on if
there is media or not. There may be RTP packets, but that doesn't mean
they contain any "real" media.

> A PROBLEM arises if there is a UAS which negotiates media but then
> sends silence (no packets) - there ARE some reasons why it might want
> to do this to do with reducing clipping on answer. The result is that
> silence would be all the caller would hear even though the UAC may
> know that the called party is being alerted. I think we just have to
> say that it is foolish for the UAS to negotiate media and then send
> silence - it should put the media on hold if it has nothing to send.

Like I said earlier, that would probably not happend when the same
server establishes the early dialog and sends the 180.  I earlier gave
an example where a B2BUA sends the announcement ("you have now reached
the X company"), the contacts a SIP phone which sends 180 (the SIP phone
does NOT generate early media). Now, the B2BUA gets the 180, stop
playing the announcement, and forwards the 180 to the UAC. Now, since
there are no more announcements, and the SIP phone doesn't generate
remote ringback, and the UAC doesn't generate local ringback, there is
no ringback at all. In this case the B2BUA would have to send UPDATE
(media on hold), then forward the 180 (the UAC will now generate local
ringback), and when the SIP phone answers it would have to send another
UPDATE (media un-hold) and then forward the 200.

An issue related to this I brought up earlier, is if the UAS will have
to buffer the 200 until both UPDATE transactions have been completed.
Any comments on that?

Also, in a non-PRACK environment, is a 18x "allowed" to establish an
early dialog in the first place? Bis-09 says that the answer must be
sent in a reliable response, which is 200 OK. Yes, bis-09 DOES say that
the answer MAY also be sent earlier, unreliably in a 18x, but when is
the early dialog actually "officially" established? Again, the UAC could
make a ringback decission based on if there is a SDP in the 180 or not,
but a unreliably sent 180 may not even arrive...

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Alexeitsev, D | 1 Jul 2002 17:29
Picon

Re: Local vs Remote ringback on 180

Hello

a comment inline

Greeting,
Denis Alexeitsev

> -----Ursprüngliche Nachricht-----
> Von: Christer Holmberg [mailto:christer.holmberg <at> lmf.ericsson.se]
> Gesendet am: Freitag, 28. Juni 2002 18:53
> An: Chris Hogg
> Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson; sip <at> ietf.org;
> Bob Penfield
> Betreff: Re: [Sip] Local vs Remote ringback on 180

However, there is no specific "remote ringback session" in SIP. You establish a generic early dialiog, by
sending an offer and receiving an answer,

[DA]As the offer/answer draft says: one "MUST be prepared to receive media" after the sending of the offer,
so it does not require for UAC to receive an answer in order to start the media playback (as the early media,
in my understanding, always come from the UAS i.e. ringback tone, announcement,... and not other way around)

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Thalapathy | 1 Jul 2002 18:29
Picon

481 response by a proxy ?

1)
 
The SIP RFC2543bis-09 only mentions 481 (call leg/transaction does not exist) as a response generated by a UAS. I donot see any specific mention of this non-2xx response generated by a proxy which had done record-route for receiving mid-dialog requests like re-INVITE.
 
 
2)
The SIP RFC2543bis-09 does not seem to discuss the behaviour of a dialog stateful proxy. Does it mean, the handling of mid-dialog requests like re-INVITEs is left to the implementation, in case there is no match found on the dialog context ? Or should the dialog stateful proxy behaviour be same as a UAS, in which case it should generate a 481 response ?
 
3)
 
What is the behaviour of a transaction stateful proxy (no dialog states maintained) when it receives a re-INVITE on a secondary server (identified by DNS) because of a primary server reboot. Does it create a new client transaction, forward the re-INVITE to the next hop ? Does it behave statelessly ? The RFC seems to be clear on handling a response recieved at a transaction stateful proxy (which does not contain the response context) by saying that the proxy MUST forward the response by behaving as a stateless proxy.
Bert Culpepper | 1 Jul 2002 19:30

RE: Local vs Remote ringback on 180

comments inline...

> -----Original Message-----
> From: sip-admin <at> ietf.org [mailto:sip-admin <at> ietf.org]On Behalf Of
> Alexeitsev, D
> Sent: Monday, July 01, 2002 11:30 AM
> To: christer.holmberg <at> lmf.ericsson.se
> Cc: sip <at> ietf.org
> Subject: Re: [Sip] Local vs Remote ringback on 180
>
>
> Hello
>
> a comment inline
>
> Greeting,
> Denis Alexeitsev
>
> > -----Ursprüngliche Nachricht-----
> > Von: Christer Holmberg [mailto:christer.holmberg <at> lmf.ericsson.se]
> > Gesendet am: Freitag, 28. Juni 2002 18:53
> > An: Chris Hogg
> > Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson;
> sip <at> ietf.org;
> > Bob Penfield
> > Betreff: Re: [Sip] Local vs Remote ringback on 180
>
>
> However, there is no specific "remote ringback session" in
> SIP. You establish a generic early dialiog, by sending an
> offer and receiving an answer,
>
> [DA]As the offer/answer draft says: one "MUST be prepared to
> receive media" after the sending of the offer, so it does not
> require for UAC to receive an answer in order to start the
> media playback (as the early media, in my understanding,
> always come from the UAS i.e. ringback tone, announcement,...
> and not other way around)
>

We want the UAC to render received media once it's sent an offer to
prevent clipping.  We need this, it causes an unacceptable user
experience if we don't do this.  In addition, we don't want to require
the UAS to provide "call progress" media, we have the 180 for it to
indicate the callee is being alerted, the UAC can convey this state to
the caller through local ringback or whatever.  It's been
proposed/discussed/and I believe there's consensus that a UAS will send
183 (or 180 recently) with SDP when it intends to present media that
should be rendered to the caller.  (Now this is not required of the UAS
but it is "polite" in that it informs the UAC of its intentions.)  The
expected UAC behavior is for it to stop "ringback" indication at this
point.

Now there's the case when the UAS is doing something more with the
session, and stops sending media to the UAC.  In this case, the caller
will not see/hear any "call progress".  What's being asked for now is
clarification on how to "ask" the UAC to again generate call progress
indication.  It's been suggested that another 18x without SDP indicate
this scenario.  As Christer indicated, there are some I-Ds that describe
this behavior.  There was a period in time where there seemed to be
consensus in the WG on this.  However, offer-answer, unify, ... I-Ds
have since come along that more rigorously define "early dialogs",
meaning of SDP, etc.  And again, the presence of SDP in 18x has nothing
to do with when a UAC should generate or expect session progress
indications.  AFAIK, it's not possible in SIP to indicate to a UAC that
it should stop rendering media and go back to local generation of
progress indication.  Nor do we want to try to do this in SIP.

IMHO, services/applications that will generate early media and then stop
have the responsibility to make the caller's user experience acceptable
(i.e., by playing an announcement, music, or whatever).  In Christer's
B2BUA example, the B2BUA's UAC assumes the responsibility to provide
call progress indication to its user (which is another UAC).

We should only recommend that a UAC generate a local indication upon
receipt of a 180 and then stop upon receipt of media (which it should
render).  Services such as Christer's example must take it upon
themselves to provide an acceptable user experience.  Otherwise we add
complexity to the protocol and degrade both interoperability and user
experience.

This is what I'd propose be the "official" clarification.  My 2 cents
anyway.

Regards,
Bert

>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Pete Cordell | 1 Jul 2002 19:24

Re: Proposed change in draft-ietf-sip-nat

Simply because it is the agreed strategy of the pre-midcom design group to
define something called SPAN.

It may not look like SPAN-A, and it may look more like TURN, but there is a
way to go before that happens.

Much of the mentioned the lack of consensus has been down to a lack of
reading rather than any identified technical issues, so I suggest we go with
the agreed name rather than starting a bun fight before we've identified and
discussed any technical problems.  To do otherwise is just creating ill will
at a time we don't need it (at least I'm assuming that people don't want it
at this stage).

Pete.

----- Original Message -----
From: "Cullen Jennings" <fluffy <at> cisco.com>
To: "Pete Cordell" <pcordell <at> ridgewaysystems.com>; <sip <at> ietf.org>
Cc: "Jonathan Rosenberg" <jdrosen <at> dynamicsoft.com>
Sent: 28 June 2002 19:35
Subject: RE: [Sip] Proposed change in draft-ietf-sip-nat

>
> My read of the SPAN document was it did not even represent consensus of
the
> design team much less the midcom WG.
>
> Why should references to TURN or SPAM be changed to just SPAN?
>
> Thanks, Cullen
>
> > -----Original Message-----
> > From: sip-admin <at> ietf.org [mailto:sip-admin <at> ietf.org]On Behalf Of Pete
> > Cordell
> > Sent: Friday, June 28, 2002 2:16 AM
> > To: Jonathan Rosenberg; sip <at> ietf.org
> > Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat
> >
> >
> > Sounds reasonable except that to be in line with the pre-midcom / midcom
> > work all references to TURN should be to SPAN (Simple Protocol for
> > Augmenting NATs), at least for the time being.
> >
> > For those that are interested, a candidate for SPAN is at:
> >
> > http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt
> >
> > But be advised that this is iteration 1 and so subject to change.
> >
> > Pete.
> >
> > ----- Original Message -----
> > From: "Jonathan Rosenberg" <jdrosen <at> dynamicsoft.com>
> > To: <sip <at> ietf.org>
> > Sent: 28 June 2002 06:06
> > Subject: [Sip] Proposed change in draft-ietf-sip-nat
> >
> >
> > > Folks,
> > >
> > > I would like to propose a change in draft-ietf-sip-nat.
> > >
> > > Right now, this document specifies two very independent and orthogonal
> > > things. One of them is the rport parameter. This is a Via param that
> > > makes sure that the SIP response gets routed back to the source IP and
> > > port where the request came from. Without it, SIP over UDP doesn't
work
> > > through any NATs. It allows SIP to work like most other protocols in
> > > terms of its port usage. I think its uncontroversial and should move
> > > forward as is.
> > >
> > > THe other aspect is the Translate header. Its aimed at making
> > > registrations work through NAT. However, there are several problems
with
> > > the Translate header right now:
> > >
> > > 1. It "competes" with other solutions, such as STUN and TURN/SPAN,
which
> > > would allow for incoming INVITEs through NAT without any SIP specific
> > > extensions.
> > >
> > > 2. It tries to optimize for the full-cone case, by including a
parameter
> > > that indicates whether the client is behind a full-cone or symmetric
> > > NAT. I would rather not pollute SIP with this kind of NAT-specific
> > > stuff; rather, relegate it to STUN/TURN.
> > >
> > > 3. UDP registrations through NAT are really troublesome. They require
> > > very frequent re-registrations to maintain the binding (under a
minute).
> > > This poses a serious load. If you have to use UDP, a STUN or TURN
> > > solution is much better, since refreshes of the NAT bindings would
occur
> > > through those protocols, rather than SIP, and they scale much better.
> > > So, if you consider TCP (which works even better still, since you
don't
> > > need to refresh the registration in order to keep the binding active),
> > > the problem is not really translating the contact header as it is TCP
> > > connection reuse for incoming requests. Indeed, the same problem
occurs
> > > in record-routing - you want to be able to specify to your peer to
reuse
> > > the connection for incoming requests. Thats not even a nat-specific
> > > thing; its just a capability that, if we had a better story on, would
be
> > > useful for NAT.
> > >
> > >
> > > As a result, I would propose that draft-ietf-sip-nat move forward with
> > > just the rport stuff, and we look at the registration problem
> > > separately. I would like a solution for SIP that didn't depend on
> > > STUN/TURN, but I have convinced myself that this solution needs to be
> > > TCP-based, and that it is best viewed as a problem of connection
reuse.
> > > ROhan has posted a requirement draft on that topic.
> > >
> > > Flame away....
> > >
> > > -Jonathan R.
> > >
> > >
> > >
> > >
> > > --
> > > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > > Chief Scientist                         First Floor
> > > dynamicsoft                             East Hanover, NJ 07936
> > > jdrosen <at> dynamicsoft.com                 FAX: (973) 952-5050
> > > http://www.jdrosen.net                  PH:  (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors <at> cs.columbia.edu for questions on current sip
> > > Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
> > Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip


Gmane