|
List Info
Thread: Need for RPH in SIP Responses
|
|
| Need for RPH in SIP Responses |
 
United States |
2007-11-21 14:56:09 |
|
Hi!
The SIP Resource Priority Header (RPH), in its current form,
is not allowed in SIP responses. This was a design choice during RFC 4412's
development. This is not a good choice in certain scenarios. The Internet Draft,
"Allowing SIP Resource Priority Header in SIP Responses" (draft-polk-sip-rph-in-responses-00)
describes a modification to RFC4412 to permit RPH in responses. The Internet
Draft, “Requirements for SIP Resource Priority Header in SIP Responses”
(draft-gunn-sip-req-for-rph-in-responses-00), describes one of the requirements
associated with systems using RPH, that could be easily met by the modification
of RFC 4412 to permit RPH in responses, and can not be easily met by other
methods. Additional scenarios and requirement are described below that can be
easily met if RPH is permitted in responses per
draft-polk-sip-rph-in-responses-00.
All aspects of a GETS/WPS call require priority treatment in
order to ensure that it is successfully established with priority, maintained
with adequate quality and priority, and released with priority. RFC 3261
permits stateless servers. There are scenarios involving stateless servers that
require such servers to provide priority treatment to GETS/WPS calls. Three scenarios
are described below where inclusion of RPH in SIP responses would enable a
stateless server to provide priority treatment.
- If there is congestion at a SIP
server, it is important that SIP messages (requests as well as responses) related
to a GETS/WPS call are processed with priority, and discarded last in
comparison with normal calls. Presence of RPH in SIP responses would
enable a stateless server to provide such capability.
- A network can mark IP packets
that carry SIP messages related to GETS/WPS calls with a specific DiffServ
Code Point (DSCP). This could be used as one mechanism to ensure that such
packets receive priority treatment in transport through an IP network. A
stateless server can mark IP packets that carry SIP responses in this
manner only if it recognizes the responses that are related to GETS/WPS
calls. Presence of RPH in SIP responses would enable a stateless server to
mark packets carrying SIP responses in this manner or other priority
transport mechanisms (e.g. MPLS path selection).
- On receipt of a SIP response
related to a GETS/WPS call, if a stateless server needs to invoke other
services and interact with other servers with priority, it needs to be
aware of the GETS/WPS call. Presence of RPH in SIP responses would enable
a stateless server to provide such capability.
As described in the internet draft, “Requirements for
SIP Resource Priority Header in SIP Responses”
(draft-gunn-sip-req-for-rph-in-responses-00), GETS/WPS paradigm is different
from the MLPP paradigm. One important difference between the two is that a
GETS/WPS call request from the calling party may not include an RPH. It is
possible that SIP servers (whether stateful or stateless) preceding the server
that authenticates and authorizes a GETS/WPS call request have RPH capability
but do not have the capability to identify the request as a GETS/WPS call
request. After successful authorization, the authenticating server will insert
an RPH in all requests it sends. In this scenario, the servers preceding the
authenticating servers would not become aware of the priority nature of the
call and would not provide any priority treatment until they receive a SIP
request with an RPH from the authenticating server. This is not desirable.
This situation can be easily remedied if RPH is permitted in SIP responses.
As has been pointed out earlier, possible security risk of
permitting RPH in SIP responses is minimal in managed IP networks where this
capability is generally expected to be used.
Regards,
Niranjan Sandesara
|
| Re: Need for RPH in SIP Responses |
 
Netherlands |
2007-11-21 15:14:08 |
Niranjan,
> As has been pointed out earlier, possible security risk
of permitting
> RPH in SIP responses is minimal in managed IP networks
where this
> capability is generally expected to be used.
>
For this argument to apply, the element sending the RPH
header in a
response and the element acting on it should both be in the
same domain.
In other words you are talking about a closed system, a very
specific
environment. The use of this header in this way then clearly
does not
apply to the Internet; the proper way to standardize this is
as a
P-header (instead of taking a header which is already
defined in a
"approved-for-the-Internet" RFC, and modifying its
allowed use to
accommodate for a non-Internet use)
Regards,
Jeroen
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
|
| RE: Need for RPH in SIP Responses |
United States |
2007-11-21 15:44:23 |
Jeroen,
It does apply to a concatenation of managed networks, lets
say
UE-AT&T-Verizon-UE...Oh, this is the same concatenation
for what you are
referring to as the "internet"..right? Only
difference is a different
portion of our IP backbones.
More important here (please just don't cut/paste the above
without
this), for wireless access the user's priority level may
change based on
call processing, including authentication, and this needs to
be relayed
back to the wireless access.
Cheers,
Martin
-----Original Message-----
From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
Sent: Wednesday, November 21, 2007 4:14 PM
To: Sandesara, Niranjan B
Cc: sipietf.org
Subject: Re: [Sip] Need for RPH in SIP Responses
Niranjan,
> As has been pointed out earlier, possible security risk
of permitting
> RPH in SIP responses is minimal in managed IP networks
where this
> capability is generally expected to be used.
>
For this argument to apply, the element sending the RPH
header in a
response and the element acting on it should both be in the
same domain.
In other words you are talking about a closed system, a very
specific
environment. The use of this header in this way then clearly
does not
apply to the Internet; the proper way to standardize this is
as a
P-header (instead of taking a header which is already
defined in a
"approved-for-the-Internet" RFC, and modifying its
allowed use to
accommodate for a non-Internet use)
Regards,
Jeroen
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
|
| Re: Need for RPH in SIP Responses |
Netherlands |
2007-11-21 16:59:32 |
Martin,
It appears we have a different view on what constitutes the
Internet -
perhaps because I am not from the US. In any case, I was
referring to
the Internet as a whole, exactly as in RFC3455:
The SIP extensions specified in this document make certain
assumptions regarding network topology, linkage between
SIP and lower
layers, and the availability of transitive trust. These
assumptions
are generally NOT APPLICABLE in the Internet as a whole.
The proposed mechanism is only secure under assumptions that
do not hold
in the Internet as a whole. It is not only a minor change
from the
current RPH usage, as draft-polk-sip-rph-in-responses-00
tries to say
("The only new security threat...")
To me, there are 3 things that could happen:
1. ignore/accept it and generate an RFC
2. define additional security measures to mitigate
3. consider a different solution
Regards,
Jeroen
DOLLY, MARTIN C, ATTLABS wrote:
> Jeroen,
>
> It does apply to a concatenation of managed networks,
lets say
> UE-AT&T-Verizon-UE...Oh, this is the same
concatenation for what you are
> referring to as the "internet"..right? Only
difference is a different
> portion of our IP backbones.
>
> More important here (please just don't cut/paste the
above without
> this), for wireless access the user's priority level
may change based on
> call processing, including authentication, and this
needs to be relayed
> back to the wireless access.
>
> Cheers,
>
> Martin
>
> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
> Sent: Wednesday, November 21, 2007 4:14 PM
> To: Sandesara, Niranjan B
> Cc: sipietf.org
> Subject: Re: [Sip] Need for RPH in SIP Responses
>
> Niranjan,
>
>
>> As has been pointed out earlier, possible security
risk of permitting
>> RPH in SIP responses is minimal in managed IP
networks where this
>> capability is generally expected to be used.
>>
>>
> For this argument to apply, the element sending the RPH
header in a
> response and the element acting on it should both be in
the same domain.
>
> In other words you are talking about a closed system, a
very specific
> environment. The use of this header in this way then
clearly does not
> apply to the Internet; the proper way to standardize
this is as a
> P-header (instead of taking a header which is already
defined in a
> "approved-for-the-Internet" RFC, and
modifying its allowed use to
> accommodate for a non-Internet use)
>
> Regards,
> Jeroen
>
>
> _______________________________________________
> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
>
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
|
| RE: Need for RPH in SIP Responses |
United States |
2007-11-22 06:13:29 |
Again, I would like to understand whether there is a
specific issue with regard to RPH in responses, or whether
this is a discussion of a failing of RFC 4412 as published
for requests.
I am not seeing a point here that relations specifically to
RPH in responses.
Regards
Keith
> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
> Sent: Wednesday, November 21, 2007 11:00 PM
> To: DOLLY, MARTIN C, ATTLABS
> Cc: sipietf.org; Sandesara, Niranjan B
> Subject: Re: [Sip] Need for RPH in SIP Responses
>
> Martin,
>
> It appears we have a different view on what constitutes
the
> Internet - perhaps because I am not from the US. In any
case,
> I was referring to the Internet as a whole, exactly as
in RFC3455:
>
> The SIP extensions specified in this document make
certain
> assumptions regarding network topology, linkage
between
> SIP and lower
> layers, and the availability of transitive trust.
These
> assumptions
> are generally NOT APPLICABLE in the Internet as a
whole.
>
> The proposed mechanism is only secure under assumptions
that
> do not hold in the Internet as a whole. It is not only
a
> minor change from the current RPH usage, as
> draft-polk-sip-rph-in-responses-00 tries to say
("The only
> new security threat...")
>
> To me, there are 3 things that could happen:
> 1. ignore/accept it and generate an RFC
> 2. define additional security measures to mitigate 3.
> consider a different solution
>
> Regards,
> Jeroen
>
> DOLLY, MARTIN C, ATTLABS wrote:
> > Jeroen,
> >
> > It does apply to a concatenation of managed
networks, lets say
> > UE-AT&T-Verizon-UE...Oh, this is the same
concatenation for
> what you
> > are referring to as the
"internet"..right? Only difference is a
> > different portion of our IP backbones.
> >
> > More important here (please just don't cut/paste
the above without
> > this), for wireless access the user's priority
level may
> change based
> > on call processing, including authentication, and
this needs to be
> > relayed back to the wireless access.
> >
> > Cheers,
> >
> > Martin
> >
> > -----Original Message-----
> > From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
> > Sent: Wednesday, November 21, 2007 4:14 PM
> > To: Sandesara, Niranjan B
> > Cc: sipietf.org
> > Subject: Re: [Sip] Need for RPH in SIP Responses
> >
> > Niranjan,
> >
> >
> >> As has been pointed out earlier, possible
security risk of
> permitting
> >> RPH in SIP responses is minimal in managed IP
networks where this
> >> capability is generally expected to be used.
> >>
> >>
> > For this argument to apply, the element sending
the RPH header in a
> > response and the element acting on it should both
be in the
> same domain.
> >
> > In other words you are talking about a closed
system, a
> very specific
> > environment. The use of this header in this way
then
> clearly does not
> > apply to the Internet; the proper way to
standardize this is as a
> > P-header (instead of taking a header which is
already defined in a
> > "approved-for-the-Internet" RFC, and
modifying its allowed use to
> > accommodate for a non-Internet use)
> >
> > Regards,
> > Jeroen
> >
> >
> > _______________________________________________
> > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol Use
> > sip-implementorscs.columbia.edu for
questions on current sip Use
> > sippingietf.org for new developments on the
application of sip
> >
> >
>
>
> _______________________________________________
> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol Use
> sip-implementorscs.columbia.edu for questions on current
sip
> Use sippingietf.org for new developments on the
application of sip
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
|
| Re: Need for RPH in SIP Responses |
United States |
2007-11-22 06:28:37 |
As I read the documents, there is a real point that prompts
the need for
RPH in responses. This has nothing to do with stateless
proxies.
Rather, it has to do with the case where the device
assigning the RPH is
upstream of a device that needs to make use of the
information.
That situation seems to be quite reasonable, does not
require a B2BUA,
and can be reasonably recognized and acted upon in a number
of different
network topologies.
However, some of the discussion has raised questions that do
need to be
clarified in the document which actually defines the
extension. Issues
such as whether a response can have a lower priority in its
RPH than a
request, appropriately trusting / using the RPH in the
response, etc.
It appears to me that part of the confusion about those
issues is that
there are related issues (such as the scope of the RPH, and
changes
during a dialog) that apply to the original document and are
not well
specified.
Yours,
Joel M. Halpern
PS: In addition to the fact that the basic problem described
in the I-D
does not depend upon the stateless / stateful nature of the
proxy, the
reason I avoid the stateless proxy aspect is that I doubt
very much that
an RPH in a response will noticeably affect the actual
response
processing if no other steps were taken before one got to
parsing
sufficient header to get to that. Until this upstream
notification was
brought forward, I was doubtful about the use of the header
in this fashion.
DRAGE, Keith (Keith) wrote:
> Again, I would like to understand whether there is a
specific issue with regard to RPH in responses, or whether
this is a discussion of a failing of RFC 4412 as published
for requests.
>
> I am not seeing a point here that relations
specifically to RPH in responses.
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
>> Sent: Wednesday, November 21, 2007 11:00 PM
>> To: DOLLY, MARTIN C, ATTLABS
>> Cc: sipietf.org; Sandesara, Niranjan B
>> Subject: Re: [Sip] Need for RPH in SIP Responses
>>
>> Martin,
>>
>> It appears we have a different view on what
constitutes the
>> Internet - perhaps because I am not from the US. In
any case,
>> I was referring to the Internet as a whole, exactly
as in RFC3455:
>>
>> The SIP extensions specified in this document make
certain
>> assumptions regarding network topology, linkage
between
>> SIP and lower
>> layers, and the availability of transitive
trust. These
>> assumptions
>> are generally NOT APPLICABLE in the Internet as
a whole.
>>
>> The proposed mechanism is only secure under
assumptions that
>> do not hold in the Internet as a whole. It is not
only a
>> minor change from the current RPH usage, as
>> draft-polk-sip-rph-in-responses-00 tries to say
("The only
>> new security threat...")
>>
>> To me, there are 3 things that could happen:
>> 1. ignore/accept it and generate an RFC
>> 2. define additional security measures to mitigate
3.
>> consider a different solution
>>
>> Regards,
>> Jeroen
>>
>> DOLLY, MARTIN C, ATTLABS wrote:
>>> Jeroen,
>>>
>>> It does apply to a concatenation of managed
networks, lets say
>>> UE-AT&T-Verizon-UE...Oh, this is the same
concatenation for
>> what you
>>> are referring to as the
"internet"..right? Only difference is a
>>> different portion of our IP backbones.
>>>
>>> More important here (please just don't
cut/paste the above without
>>> this), for wireless access the user's priority
level may
>> change based
>>> on call processing, including authentication,
and this needs to be
>>> relayed back to the wireless access.
>>>
>>> Cheers,
>>>
>>> Martin
>>>
>>> -----Original Message-----
>>> From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
>>> Sent: Wednesday, November 21, 2007 4:14 PM
>>> To: Sandesara, Niranjan B
>>> Cc: sipietf.org
>>> Subject: Re: [Sip] Need for RPH in SIP
Responses
>>>
>>> Niranjan,
>>>
>>>
>>>> As has been pointed out earlier, possible
security risk of
>> permitting
>>>> RPH in SIP responses is minimal in managed
IP networks where this
>>>> capability is generally expected to be
used.
>>>>
>>>>
>>> For this argument to apply, the element sending
the RPH header in a
>>> response and the element acting on it should
both be in the
>> same domain.
>>> In other words you are talking about a closed
system, a
>> very specific
>>> environment. The use of this header in this way
then
>> clearly does not
>>> apply to the Internet; the proper way to
standardize this is as a
>>> P-header (instead of taking a header which is
already defined in a
>>> "approved-for-the-Internet" RFC, and
modifying its allowed use to
>>> accommodate for a non-Internet use)
>>>
>>> Regards,
>>> Jeroen
>>>
>>>
>>>
_______________________________________________
>>> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core
SIP Protocol Use
>>> sip-implementorscs.columbia.edu for
questions on current sip Use
>>> sippingietf.org for new developments on the
application of sip
>>>
>>>
>>
>> _______________________________________________
>> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol Use
>> sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip
>>
>
>
> _______________________________________________
> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
|
| RE: Need for RPH in SIP Responses |
United States |
2007-11-22 10:43:58 |
Just to be clear, I personally was not arguing against the
use cases.
I was pointing out that issues were being raised in
discussing RPH in responses that were nothing to do with the
new use cases, but appeared to be equally issues with RPH in
requests.
Such discussion is an issue with RFC 4412, not an issue with
either author draft, and should be discussed, but on a
different thread.
Regards
Keith
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmhjoelhalpern.com]
> Sent: Thursday, November 22, 2007 12:29 PM
> To: DRAGE, Keith (Keith)
> Cc: Jeroen van Bemmel; DOLLY, MARTIN C, ATTLABS;
> sipietf.org; Sandesara, Niranjan B
> Subject: Re: [Sip] Need for RPH in SIP Responses
>
> As I read the documents, there is a real point that
prompts
> the need for RPH in responses. This has nothing to do
with
> stateless proxies.
> Rather, it has to do with the case where the device
assigning
> the RPH is upstream of a device that needs to make use
of the
> information.
>
> That situation seems to be quite reasonable, does not
require
> a B2BUA, and can be reasonably recognized and acted
upon in a
> number of different network topologies.
>
> However, some of the discussion has raised questions
that do
> need to be clarified in the document which actually
defines
> the extension. Issues such as whether a response can
have a
> lower priority in its RPH than a request, appropriately
> trusting / using the RPH in the response, etc.
> It appears to me that part of the confusion about those
> issues is that there are related issues (such as the
scope of
> the RPH, and changes during a dialog) that apply to the
> original document and are not well specified.
>
> Yours,
> Joel M. Halpern
>
> PS: In addition to the fact that the basic problem
described
> in the I-D does not depend upon the stateless /
stateful
> nature of the proxy, the reason I avoid the stateless
proxy
> aspect is that I doubt very much that an RPH in a
response
> will noticeably affect the actual response processing
if no
> other steps were taken before one got to parsing
> sufficient header to get to that. Until this upstream
> notification was
> brought forward, I was doubtful about the use of the
header
> in this fashion.
>
> DRAGE, Keith (Keith) wrote:
> > Again, I would like to understand whether there is
a
> specific issue with regard to RPH in responses, or
whether
> this is a discussion of a failing of RFC 4412 as
published
> for requests.
> >
> > I am not seeing a point here that relations
specifically to
> RPH in responses.
> >
> > Regards
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: Jeroen van Bemmel [mailto:jbemmelzonnet.nl]
> >> Sent: Wednesday, November 21, 2007 11:00 PM
> >> To: DOLLY, MARTIN C, ATTLABS
> >> Cc: sipietf.org; Sandesara, Niranjan B
> >> Subject: Re: [Sip] Need for RPH in SIP
Responses
> >>
> >> Martin,
> >>
> >> It appears we have a different view on what
constitutes
> the Internet
> >> - perhaps because I am not from the US. In any
case, I was
> referring
> >> to the Internet as a whole, exactly as in
RFC3455:
> >>
> >> The SIP extensions specified in this document
make certain
> >> assumptions regarding network topology,
linkage between SIP and
> >> lower
> >> layers, and the availability of transitive
trust. These
> >> assumptions
> >> are generally NOT APPLICABLE in the
Internet as a whole.
> >>
> >> The proposed mechanism is only secure under
assumptions
> that do not
> >> hold in the Internet as a whole. It is not
only a minor
> change from
> >> the current RPH usage, as
> draft-polk-sip-rph-in-responses-00 tries to
> >> say ("The only new security
threat...")
> >>
> >> To me, there are 3 things that could happen:
> >> 1. ignore/accept it and generate an RFC 2.
define
> additional security
> >> measures to mitigate 3.
> >> consider a different solution
> >>
> >> Regards,
> >> Jeroen
> >>
> >> DOLLY, MARTIN C, ATTLABS wrote:
> >>> Jeroen,
> >>>
> >>> It does apply to a concatenation of
managed networks, lets say
> >>> UE-AT&T-Verizon-UE...Oh, this is the
same concatenation for
> >> what you
> >>> are referring to as the
"internet"..right? Only difference is a
> >>> different portion of our IP backbones.
> >>>
> >>> More important here (please just don't
cut/paste the
> above without
> >>> this), for wireless access the user's
priority level may
> >> change based
> >>> on call processing, including
authentication, and this
> needs to be
> >>> relayed back to the wireless access.
> >>>
> >>> Cheers,
> >>>
> >>> Martin
> >>>
> >>> -----Original Message-----
> >>> From: Jeroen van Bemmel
[mailto:jbemmelzonnet.nl]
> >>> Sent: Wednesday, November 21, 2007 4:14
PM
> >>> To: Sandesara, Niranjan B
> >>> Cc: sipietf.org
> >>> Subject: Re: [Sip] Need for RPH in SIP
Responses
> >>>
> >>> Niranjan,
> >>>
> >>>
> >>>> As has been pointed out earlier,
possible security risk of
> >> permitting
> >>>> RPH in SIP responses is minimal in
managed IP networks
> where this
> >>>> capability is generally expected to be
used.
> >>>>
> >>>>
> >>> For this argument to apply, the element
sending the RPH
> header in a
> >>> response and the element acting on it
should both be in the
> >> same domain.
> >>> In other words you are talking about a
closed system, a
> >> very specific
> >>> environment. The use of this header in
this way then
> >> clearly does not
> >>> apply to the Internet; the proper way to
standardize this is as a
> >>> P-header (instead of taking a header which
is already
> defined in a
> >>> "approved-for-the-Internet" RFC,
and modifying its allowed use to
> >>> accommodate for a non-Internet use)
> >>>
> >>> Regards,
> >>> Jeroen
> >>>
> >>>
> >>>
_______________________________________________
> >>> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the
core SIP Protocol Use
> >>> sip-implementorscs.columbia.edu for
questions on current sip Use
> >>> sippingietf.org for new
developments on the application of sip
> >>>
> >>>
> >>
> >>
_______________________________________________
> >> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core
SIP Protocol Use
> >> sip-implementorscs.columbia.edu for
questions on current sip Use
> >> sippingietf.org for new developments on the
application of sip
> >>
> >
> >
> > _______________________________________________
> > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol Use
> > sip-implementorscs.columbia.edu for
questions on current sip Use
> > sippingietf.org for new developments on the
application of sip
> >
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
|
[1-7]
|
|