IETF Secretariat | 5 Mar 07:25 2013
Picon

IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 5626


Dear Cullen Jennings:

 An IPR disclosure that pertains to your RFC entitled "Managing Client-Initiated
Connections in the Session Initiation Protocol (SIP)" (RFC5626) was submitted to
the IETF Secretariat on 2013-02-23 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/1992/). The title of the IPR disclosure is
"SSH Communications Security Corporation's Statement about IPR related to RFC
5626."");

The IETF Secretariat
IETF Secretariat | 5 Mar 07:21 2013
Picon

IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 4028


Dear Jonathan Rosenberg, Steven Donovan:

 An IPR disclosure that pertains to your RFC entitled "Session Timers in the
Session Initiation Protocol (SIP)" (RFC4028) was submitted to the IETF
Secretariat on 2013-02-23 and has been posted on the "IETF Page of Intellectual
Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1979/). The title
of the IPR disclosure is "SSH Communications Security Corporation's Statement
about IPR related to RFC 4028."");

The IETF Secretariat
IETF Secretariat | 20 Jul 19:26 2012
Picon

IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 5627


Dear Jonathan Rosenberg:

 An IPR disclosure that pertains to your RFC entitled "Obtaining and Using
Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)" (RFC5627) was submitted to the IETF Secretariat on 2012-07-19 and has
been posted on the "IETF Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/1832/). The title of the IPR disclosure is
"Microsoft Corporation's Statement about IPR related to RFC 5627."");

The IETF Secretariat
Robert Sparks | 7 Dec 23:40 2011

Closing the SIP and SIPPING mailing lists

Folks -

When we closed the SIP and SIPPING working groups in 2009, we left the 
mail lists open
to ensure we had a venue for any remaining business and to help people 
migrate to the
new lists. Based on several recent requests, and after consulting with 
the list moderators,
we are closing the old lists to new messages.

The archives will continue to be maintained in their current location.

RjS
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

Javi Muñoz | 30 Nov 18:59 2011
Picon

ISDN/SIP interworking [ETSI TS 183 036]

Three questions about it:

(a) ISDN/SIP interworking spec [ETSI TS 183 036] proposes that in the 
Q.931/SIP interworking, some EIs Q.931 are codec to SDP and/or inserted 
in the SIP body as a PSTN XML element.
Under what criteria, an Q.931 EI should be?:

(1) Coding to SDP

AND / OR  (this is also important)

(2) Inserted in the SIP body as a PSTN XML element

or

(3) Coding to the URI SIP or and SIP header

or

(4) None (only interpreted by the AGW, without being carried over SIP)

(b) Why does [ETSI TS 183 036]define the mapping of the IE "User to 
user" to the SIP header User-to-User [draft-johnston-sipping-cc-uui-09], 
instead of transporting it over an PSTN XML element? (the IE "User to 
user" must be transported transparently by the nerwork)

(c) Although as optional, [ETSI TS 183 036]defines the coding to SDP of 
the "High Layer Characteristics Identification" field of the IE 
HLC[Q.931].According to Q.931, this EI HLC should be used by the 
end-to-end terminals, not by the LEs (or AGWs in NGN). Then:
(Continue reading)

RUOFF, LARS (LARS)** CTR ** | 18 Nov 09:22 2011

SDP telephone-event (DTMF) payload negotiation

Hi all,

New to this list. Apologies if this question has been asked many times before (my searches showed that it
has, but i was still unable to find a definitive answer).

The question is about SDP telephone-event (DTMF) payload negotiation.

Imagine the following call setup between A and B:
INVITE A->B
SDP:
(among other media formats)
a=sendrecv
a=rtpmap:101 telephone-event/8000

200 OK B->A
SDP:
(among other media formats)
a=sendrecv
a=rtpmap:97 telephone-event/8000

The question is:
Is the above legal? I.e. is B allowed to choose a different PT than proposed y A. 
In case yes, what PT should the telephone-events be sent...
from A to B?
from B to A?

Please corroborate your answers by providing normative references if possible.

I studied RFC 3264 (SDP Offer/Answer Model) intensively, but could not conclude for a definitive answer in
that particular case.
(Continue reading)

VARUN AGRAWAL | 18 Nov 05:11 2011
Picon

101 dialog establishment/ambiguous

hi,

what is the functioning of 101 dialog establishment/ambiguous in SIP message

regards,
Varun
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Lewis Adam-CAL022 | 8 Nov 14:51 2011

Question on rfc4474

Hi all,

rfc4474 describes how an Authentication Service - which might be
implemented in a SIP proxy - can make digital signatures which provide
assurance for SIP applications that the asserted SIP identity is valid.
It recommends implementing this service within a SIP proxy since the SIP
proxy 1) is likely to have a private signing key, and 2) has access to
SIP registrar services.  It is the second part I have a question about.

If a network has a dedicated SIP proxy and a dedicated SIP registrar,
and a SIP user registers with the SIP registrar using HTTP digest, then
how does this help the SIP proxy validate the identity of the SIP user,
such that it can add a digital signature to SIP messages received from
the UE?  A few things come to mind:

* User can authenticates separately to the SIP proxy and create an
authenticated user session with it
* Something like IMS, where successful registration with the S-CSCF
results in an authenticated IPsec SA between the UE and P-CSCF
* Co-located SIP proxy and SIP registrar in the same box
* Others?

I'm guessing that the RFC intentionally did not address the "how" of
this and leaves it to implementation, just want to make sure I'm not
missing something.  Are there any other well known ways to solve this
other than those I mention above?

Tx!
adam

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

Iñaki Baz Castillo | 23 Oct 13:22 2011
Picon

Which WG RFC 5626 belongs to?

Hi, I would like to make some comments about RFC 5626 (Outbound) but
honestly I don't know which WG is the responsible of such RFC.
Could you point me to the right WG?

Thanks a lot.

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Iñaki Baz Castillo | 14 Oct 13:52 2011
Picon

RFC 5626 (Outbound) hard to understand non-register request processing

Hi, RFC 5626 section 5.3 "Forwarding Non-REGISTER Requests" says:

5.3.  Forwarding Non-REGISTER Requests

   When an edge proxy receives a request, it applies normal routing
   procedures with the following additions.  If the edge proxy receives
   a request where the edge proxy is the host in the topmost Route
   header field value, and the Route header field value contains a flow
   token, the proxy follows the procedures of this section.  Otherwise
   the edge proxy skips the procedures in this section, removes itself
   from the Route header field, and continues processing the request.

And then in section 5.3.2 "Processing Outgoing Requests" (which is
*into* section 5.3) it talks about:

   If the edge proxy receives an outgoing dialog-forming request, the
   edge proxy can use the presence of the "ob" URI parameter in the
   UAC's Contact URI (or topmost Route header field) to determine if the
   edge proxy needs to assist in mid-dialog request routing.

The problem is that an initial INVITE/SUBSCRIBE sent from a outbound
SIP client won't have a flow token in a Route header, so the text in
5.3 suggests doing nothing special for such request. The reader could
then ignore section 5.3.2 in which, clearly, the edge proxy should
assist in-dialog request routing for this initial request (by adding a
flow token in the Record-Route).

Do I miss something? or the text is indeed confusing?

Thanks.

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
kiran kumar | 11 Oct 19:59 2011
Picon

How to determine MO and MT call in SIP Networks

Hi all,

I am developing a SIPB2B which acts as a session controller.
No registration mechanism is implemented in it.
It will directly receives Invite from UAC and forwards it to UAS after successful billing authentication.

Can any one help me, how could I distinguish between MO and MT calls (In pure SIP networks).
Is there any SIP header to determine the call type.

Thanks,
Kiran.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

Gmane