gmane.ietf.sip

Closing the SIP and SIPPING mailing lists

Robert Sparks — 2011-12-07T22:40:38

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.

ISDN/SIP interworking [ETSI TS 183 036]

Javi Muñoz — 2011-11-30T17:59:24

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:
(1) Why this SDP coding?
(2) And why is it optional?

Regards,

Javi
_______________________________________________
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.

Re: SDP telephone-event (DTMF) payload negotiation

Paul Kyzivat — 2011-11-23T17:36:35

In retrospect, yes. But the RFC has been published already.
You can file an errata report. That will probably be queued pending a 
revision to the RFC.

Thanks,
Paul


_______________________________________________
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.

Re: SDP telephone-event (DTMF) payload negotiation

RUOFF, LARS (LARS)** CTR ** — 2011-11-22T10:25:11

Thanks, Paul.


That's how I understood it, too. But it seems that opinions diverge on this.
Maybe the RFC authors should insist on the above a bit more explicitely.

Regards,
Lars

-----Original Message-----
From: sip-bounces< at >ietf.org [mailto:sip-bounces< at >ietf.org] On Behalf Of Paul Kyzivat
Sent: vendredi 18 novembre 2011 13:04
To: sip< at >ietf.org
Subject: Re: [Sip] SDP telephone-event (DTMF) payload negotiation

On 11/18/11 4:22 PM, RUOFF, LARS (LARS)** CTR ** wrote:

 From section 6.1:

    In the case of RTP, if a particular codec was referenced with a
    specific payload type number in the offer, that same payload type
    number SHOULD be used for that codec in the answer.  Even if the same
    payload type number is used, the answer MUST contain rtpmap
    attributes to define the payload type mappings for dynamic payload
    types, and SHOULD contain mappings for static payload types.  The
    media formats in the "m=" line MUST be listed in order of preference,
    with the first format listed being preferred.  In this case,
    preferred means that the offerer SHOULD use the format with the
    highest preference from the answer.
...
    Once the answerer has sent the answer, it MUST be prepared to receive
    media for any recvonly streams described by that answer.  It MUST be
    prepared to send and receive media for any sendrecv streams in the
    answer, and it MAY send media immediately.  The answerer MUST be
    prepared to receive media for recvonly or sendrecv streams using any
    media formats listed for those streams in the answer, and it MAY send
    media immediately.  When sending media, it SHOULD use a packetization
    interval equal to the value of the ptime attribute in the offer, if
    any was present.  It SHOULD send media using a bandwidth no higher
    than the value of the bandwidth attribute in the offer, if any was
    present.  The answerer MUST send using a media format in the offer
    that is also listed in the answer, and SHOULD send using the most
    preferred media format in the offer that is also listed in the
    answer.  In the case of RTP, it MUST use the payload type numbers
    from the offer, even if they differ from those in the answer.

 From section 7:

    When the offerer receives the answer, it MAY send media on the
    accepted stream(s) (assuming it is listed as sendrecv or recvonly in
    the answer).  It MUST send using a media format listed in the answer,

 From the above, "the same payload type number SHOULD be used", so its possible that a different payload type is used. And if so,

- the answerer must send with the pt listed in the offer
- the offerer must send with a media format listed in the answer

It doesn't quite say that the offerer must send with a pt listed in the answer, but its clear for consistency that it should. That is widely understood to be the intent.

Thanks,
Paul
_______________________________________________
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.
_______________________________________________
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.

Re: SDP telephone-event (DTMF) payload negotiation

Paul Kyzivat — 2011-11-18T12:04:02

From section 6.1:

In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer. Even if the same
payload type number is used, the answer MUST contain rtpmap
attributes to define the payload type mappings for dynamic payload
types, and SHOULD contain mappings for static payload types. The
media formats in the "m=" line MUST be listed in order of preference,
with the first format listed being preferred. In this case,
preferred means that the offerer SHOULD use the format with the
highest preference from the answer.
...
Once the answerer has sent the answer, it MUST be prepared to receive
media for any recvonly streams described by that answer. It MUST be
prepared to send and receive media for any sendrecv streams in the
answer, and it MAY send media immediately. The answerer MUST be
prepared to receive media for recvonly or sendrecv streams using any
media formats listed for those streams in the answer, and it MAY send
media immediately. When sending media, it SHOULD use a packetization
interval equal to the value of the ptime attribute in the offer, if
any was present. It SHOULD send media using a bandwidth no higher
than the value of the bandwidth attribute in the offer, if any was
present. The answerer MUST send using a media format in the offer
that is also listed in the answer, and SHOULD send using the most
preferred media format in the offer that is also listed in the
answer. In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer.

From section 7:

When the offerer receives the answer, it MAY send media on the
accepted stream(s) (assuming it is listed as sendrecv or recvonly in
the answer). It MUST send using a media format listed in the answer,

From the above, "the same payload type number SHOULD be used", so its
possible that a different payload type is used. And if so,

- the answerer must send with the pt listed in the offer
- the offerer must send with a media format listed in the answer

It doesn't quite say that the offerer must send with a pt listed in the
answer, but its clear for consistency that it should. That is widely
understood to be the intent.

Thanks,
Paul
_______________________________________________
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.

SDP telephone-event (DTMF) payload negotiation

RUOFF, LARS (LARS)** CTR ** — 2011-11-18T08:22:05

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.

Regards,
Lars Ruoff
_______________________________________________
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.

Re: 101 dialog establishment/ambiguous

Iñaki Baz Castillo — 2011-11-18T07:11:19

2011/11/18 VARUN AGRAWAL <varun_swn< at >yahoo.co.in>:

Such status code is not standarized:

  http://www.iana.org/assignments/sip-parameters

As I see, 101 status code is used by eXosip SIP stack:

  http://www.atosc.org/pipermail/osip/2006-February/006305.html

101 dialog establishment/ambiguous

VARUN AGRAWAL — 2011-11-18T04:11:38

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.

Question on rfc4474

Lewis Adam-CAL022 — 2011-11-08T13:51:31

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.

Re: Which WG RFC 5626 belongs to?

Iñaki Baz Castillo — 2011-10-23T11:24:46

2011/10/23 Iñaki Baz Castillo <ibc< at >aliax.net>:

Sorry, found it: Dispatch WG.

Which WG RFC 5626 belongs to?

Iñaki Baz Castillo — 2011-10-23T11:22:54

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.

RFC 5626 (Outbound) hard to understand non-register requestprocessing

Iñaki Baz Castillo — 2011-10-14T11:52:23

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.

Re: How to determine MO and MT call in SIP Networks

Iñaki Baz Castillo — 2011-10-11T18:06:06

2011/10/11 kiran kumar <g.kiranreddy4u< at >gmail.com>:

Hi Kiran. Please use sip-implementors maillist.

How to determine MO and MT call in SIP Networks

kiran kumar — 2011-10-11T17:59:55

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.

[Editorial Errata Reported] RFC6072 (2988)

RFC Errata System — 2011-10-10T19:00:13

The following errata report has been submitted for RFC6072,
"Certificate Management Service for the Session Initiation Protocol (SIP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6072&eid=2988

--------------------------------------
Type: Editorial
Reported by: Olle E. Johansson <oej< at >edvina.net>

Section: 8

Original Text
-------------
The [RFC4474] authentication service defined a signature algorithm
based on SHA-1 called rsa-sha1. This specification adds a signature
algorithm that is roughly the same but based on SHA-256 and called
rsa-sha256.

Corrected Text
--------------
The [RFC4474] authentication service defined a signature algorithm
based on SHA-1 called rsa-sha1. This specification adds a signature
algorithm that is roughly the same but based on SHA-256 and called
rsa-sha256. This is an update of RFC 4474.

Notes
-----
The Masthead doesn't indicate clearly that this RFC updates 4474 and thus the IETF tools web site doesn't indicate that 4474 is updated.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6072 (draft-ietf-sip-certs-15)
--------------------------------------
Title : Certificate Management Service for the Session Initiation Protocol (SIP)
Publication Date : February 2011
Author(s) : C. Jennings, J. Fischl, Ed.
Category : PROPOSED STANDARD
Source : Session Initiation Protocol
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
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.

Re: Using TLS in the first hop - Bug in RFC 5630

DRAGE, Keith (Keith — 2011-10-08T09:08:56

All drafts help things along, but please do have the discussion on DISPATCH or SIPCORE.

It doesn't belong here.

Keith

________________________________
From: Samir Srivastava [mailto:samirs.lists< at >gmail.com]
Sent: 07 October 2011 20:34
To: DRAGE, Keith (Keith)
Cc: Hadriel Kaplan; Iñaki Baz Castillo; <sip< at >ietf.org>; Olle E. Johansson
Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630

In line prefixed with SS>>

Regards
Samir

On Thu, Sep 15, 2011 at 10:05 AM, DRAGE, Keith (Keith) <keith.drage< at >alcatel-lucent.com<mailto:keith.drage< at >alcatel-lucent.com>> wrote:
Addressing the thread in general rather than Hadriel in particular.

Please remember that RFC 5630 did not set out to create a complete solution to secure communication. That was left to separate work and noone at the time seemed interested in doing that next step, so it was abandoned.

SS>> Refer the draft   http://datatracker.ietf.org/doc/draft-srivastava-dispatch-avoidance-of-threats/  submitted recently. And let me know your comments. What we intend to do in future? As per my recollection Security Advisor was not in agreement with my proposal. But it was told that there will be a day when this solution will be needed,

What RFC 5630 set out to do was to define what occurred if you followed the RFC 3261 mechanisms, and to correct some of RFC 3261 that was known to be wrong and to attempt to make sure that if SIPS was used in the Request-URI, then TLS was used end to end. I do not believe there was ever an intent to try and control what happened hop by hop. If you know that TLS is being used on the local hop, but have absolutely no knowledge of whether it is being used anywhere else, how useful is that?

While section 5, the normative section appears somewhat long, if you look at the impact of RFC 5630 in the way it changed RFC 3261 as stated in appendix A, it actually did very little in terms of change to the original RFC 3261 material.

I'm not actually sure that the issue you point out in 3.1.3 actually impacts the above drastically.

Do note however that if you want to perform new work, you probably need to take it to the SIPCORE list.

Keith

_______________________________________________
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<mailto:sip-implementors< at >cs.columbia.edu> for questions on how to develop a SIP implementation.
Use dispatch< at >ietf.org<mailto:dispatch< at >ietf.org> for new developments on the application of sip.
Use sipcore< at >ietf.org<mailto:sipcore< at >ietf.org> for issues related to maintenance of the core SIP specifications.

_______________________________________________
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.

Re: Using TLS in the first hop - Bug in RFC 5630

Samir Srivastava — 2011-10-07T19:33:34

In line prefixed with SS>>

Regards
Samir

On Thu, Sep 15, 2011 at 10:05 AM, DRAGE, Keith (Keith) <
keith.drage< at >alcatel-lucent.com> wrote:


SS>> Refer the draft
http://datatracker.ietf.org/doc/draft-srivastava-dispatch-avoidance-of-threats/
submitted recently. And let me know your comments. What we intend to do in
future? As per my recollection Security Advisor was not in agreement with my
proposal. But it was told that there will be a day when this solution will
be needed,




_______________________________________________
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.

Re: Using TLS in the first hop - Bug in RFC 5630

Iñaki Baz Castillo — 2011-09-16T14:40:02

2011/9/16 DRAGE, Keith (Keith) <keith.drage< at >alcatel-lucent.com>:

I've started a thread in SIPCORE.

Thanks a lot.

Re: Using TLS in the first hop - Bug in RFC 5630

DRAGE, Keith (Keith — 2011-09-16T14:35:19

And just to clarify, the SIP list is addressed at the remaining work that existed in the SIP WG at the time it closed. Indeed many SIP experts have left this list, or are newcomers and were never on it.

As this is potential new work, it should follow the rules for introducing new work into the RAI area. This would ultimately end up in the SIPCORE WG. Whether the SIPCORE chairs would feel it needed to be DISPATCHed first I will leave you to consult on.

Of course what you do with it prior to the request to charter the work is entirely up to you as authors and collaborators, but at some point you need to bring other experts up to speed with what you would like IETF to do.

Regards

Keith

_______________________________________________
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.

Re: Using TLS in the first hop - Bug in RFC 5630

DRAGE, Keith (Keith — 2011-09-16T14:23:10

I would suggest moving the discussion to either SIPCORE or DISPATCH.

Keith

_______________________________________________
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.

Re: Using TLS in the first hop - Bug in RFC 5630

Iñaki Baz Castillo — 2011-09-16T14:21:50

2011/9/16 Vijay K. Gurbani <vkg< at >bell-labs.com>:

Hi Vijay, the PDF is already accesible in the link below :)



I would like to comment about this draft, is it the appropriate maillist for it?