Session Initiation Protocol (sip)

Robert Sparks | 7 Dec 2011 23:40

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.

headers

Javi Muñoz | 30 Nov 2011 18:59

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)

headers

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

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)

headers

VARUN AGRAWAL | 18 Nov 2011 05:11

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.

headers

Lewis Adam-CAL022 | 8 Nov 2011 14:51

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.

headers

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

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.

headers

Iñaki Baz Castillo | 14 Oct 2011 13:52

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.

headers

kiran kumar | 11 Oct 2011 19:59

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.

headers

RFC Errata System | 10 Oct 2011 21:00

[Editorial Errata Reported] RFC6072 (2988)

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.

headers

Iñaki Baz Castillo | 15 Sep 2011 15:01

Using TLS in the first hop - Bug in RFC 5630

Hi, there is a general confusion about the usage of TLS transport and
SIPS schema. Even more when the RFC 5630 (which tries to clarify it)
contains an important bug:

RFC 5630 states:

-------------------------------------------------------------------
3.1.3.  Using TLS with SIP Instead of SIPS

   [...]

   If one wants to use "best-effort TLS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS.

   Using SIP over TLS is very simple.  A UA opens a TLS connection and
   uses SIP URIs instead of SIPS URIs for all the header fields in a SIP
   message (From, To, Request-URI, Contact header field, Route, etc.).
   When TLS is used, the Via header field indicates TLS.
-------------------------------------------------------------------

So an example of INVITE sent via TLS just for the first hop would be:

  INVITE sip:bob <at> biloxi.com SIP/2.0
  Via: SIP/2.0/TLS 1.2.3.4
  From: sip:alice <at> atlanta.com
  Contact: sip:alice <at> 1.2.3.4;transport=tcp

Note that I've set "sip" schema in the Contact URI (as the spec says)
so incoming in-dialog request would be received by the caller (alice)
via TCP rather than TLS !!!

This is wrong, it should be:

  INVITE sip:bob <at> biloxi.com SIP/2.0
  Via: SIP/2.0/TLS 1.2.3.4
  From: sip:alice <at> atlanta.com
  Contact: sips:alice <at> 1.2.3.4;transport=tcp

Now Contact URI has "sips" schema so the proxy (assuming it does
loose-routing) would route any in-dialog request via TLS-over-TCP to
reach alice.

The fact that the Contact URI has "sips" schema is not a problem for
the called (regardless it speaks TLS or not) as in-dialog request to
be sent from Bob to Alice would contain Route headers, and those Route
headers could have "sip" schema (in case the latest proxy contacted
Bob using UDP or TCP). So a BYE from Bob would be sent via UDP/TCP
based on the top most Route.

As a personal comment, I would like to say that nobody understands the
usage of "sips" schema, just nobody. And the specs do not help.

Best regards.

--

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

headers

etherchen | 19 Aug 2011 05:17

Sent 18x with 'require:100rel' but no PRACK recieved

Hi:

I'm facing a ISUP - SIP interworking issue recently.

I receive INVITE from remote SIP server and send IAM to ISUP side, ISUP reply ACM/CPG and then I send 18x with 100rel out, but I did not receive any PRACK from remote SIP server, and I re-send 18x to them. During this period, ISUP side send ANM to me.

If connect the call, but my end haven't receive PRACK yet, it become a unreliable call.

If disconnect the call, I should not base on ANM to release a call.

If continue 18x re-transmission untill time-out, it will have charging issue. Because ISUP side start billing base on ANM already, but my SIP side haven't start charging because not answer.

Thanks.

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

1	December 2011
8	November 2011
8	October 2011
28	September 2011
18	August 2011
13	July 2011
9	June 2011
7	May 2011
21	April 2011
12	March 2011
8	February 2011
5	January 2011
1	December 2010
2	November 2010
1	October 2010
14	September 2010
3	August 2010
12	June 2010
25	May 2010
19	April 2010
23	March 2010
12	February 2010
22	January 2010
23	December 2009
5	November 2009
15	October 2009
19	September 2009
72	August 2009
7	July 2009
14	June 2009
30	May 2009
201	April 2009
522	March 2009
149	February 2009
69	January 2009
332	December 2008
543	November 2008
609	October 2008
138	September 2008
247	August 2008
431	July 2008
392	June 2008
273	May 2008
508	April 2008
384	March 2008
389	February 2008
172	January 2008
230	December 2007
518	November 2007
427	October 2007
199	September 2007
190	August 2007
574	July 2007
363	June 2007
251	May 2007
432	April 2007
441	March 2007
177	February 2007
231	January 2007
209	December 2006
443	November 2006
611	October 2006
353	September 2006
448	August 2006
729	July 2006
484	June 2006
401	May 2006
316	April 2006
747	March 2006
334	February 2006
101	January 2006
151	December 2005
198	November 2005
187	October 2005
105	September 2005
110	August 2005
172	July 2005
105	June 2005
121	May 2005
191	April 2005
173	March 2005
118	February 2005
105	January 2005
111	December 2004
287	November 2004
128	October 2004
104	September 2004
94	August 2004
160	July 2004
152	June 2004
187	May 2004
79	April 2004
117	March 2004
232	February 2004
143	January 2004
101	December 2003
165	November 2003
189	October 2003
249	September 2003
186	August 2003
90	July 2003
95	June 2003
104	May 2003
166	April 2003
130	March 2003
117	February 2003
267	January 2003
335	December 2002
230	November 2002
200	October 2002
173	September 2002
169	August 2002
274	July 2002
378	June 2002
474	May 2002
449	April 2002
1	October 2000
2	May 2000
4	April 2000

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31