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

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 ess

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 reg

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/SUBSCR

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 t

Using TLS in the first hop - Bug in RFC 5630

Iñaki Baz Castillo — 2011-09-15T13:01:22

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 Contac

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

etherchen — 2011-08-19T03:17:39

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

Fred Stacey is out of the office.

2011-08-02T19:03:51

I will be out of the office starting  07/30/2011 and will not return until
08/08/2011.

I will be out of the office  From Jully 30 to Aug 8 inclusive.
If your inquiry is regarding Mitel AnyWare, please direct to
mitel_anyware_sales< at >mitel.com.
If your inquiry is regarding MICD or the Mitel Service Provider Program,
please direct to Andrew Moses (andrew_moses< at >mitel.com)

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

[Technical Errata Reported] RFC3261 (2910)

RFC Errata System — 2011-08-02T14:53:59

The following errata report has been submitted for RFC3261,
"SIP: Session Initiation Protocol".

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

--------------------------------------
Type: Technical
Reported by: Iñaki Baz Castillo <ibc< at >aliax.net>

Section: Table 2

Original Text
-------------
      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                1xx           -   -   -   o   -   -

Corrected Text
--------------
      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                1xx           -   -   -   m   -   -

Notes
-----
RFC 3261 says:

Section 12.1: "Dialogs are created through the generation of non-failure responses to requests with specific methods.  Within this specification, only 2xx and 101-199 responses w

Types of Conference calls supported by SIP

Ruben Roque — 2011-07-27T11:24:22

Hi,

I want to learn the types of conference calls supported by SIP along
with the working and call flow.
Kindly provide me the links/RFC's for the same.

Thank you!

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

Test, please ignore

Dean Willis — 2011-07-15T17:35:34

I seem to be having a problem with the mail replicator scrambling those messages that mail.app insists on sending with a content-encoding of quoted printable. Supposedly, the apple  mail from 10.6.2+ does this whenever it is forced to deal with "long lines" but the message format is set to "plain text". I am wondering if I should just switch to mhtml format? Would this be likely to work better? Or shouldI just go to theunderbird? I do enjoy the addressbook integration in mail.app, however.

--
Dea, the bemused
_______________________________________________
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.

Codec Negotiation and renegotiataion

atul garg — 2011-07-13T15:29:40

Hello All,
 
I have very basic question regarding the codec negotiation in SIP, I will try to summarize my queries below -
 
1) If A is initiating the call and sending the supported codec list say (1,2,3)
     
    A -->  INVITE (SDP-> audio 1 2 3) --> B      ( B supports 1 , 3, 5)
    A <--  200 OK ( SDP -> what will be here 1, 2 ,3 OR 1, 3, 5)  <-- B
 
   if it is 1, 3, 5 then what will be the response to B ??
 
2)  If A is initiating the call and sending the supported codec list say (1,2,3)
     
    A -->  INVITE (SDP-> audio 1 2 3) --> B      ( B supports  2 , 3, 5)
    A <--  200 OK ( SDP -> what will be here 2 , 3 OR  2 , 3, 5)  <-- B
 
   if it is 2 , 3  then what will be the response to B ??
   if it is 2 , 3, 5  then what will be the response to B ??
 
3)  If A is initiating the call and sending the supported codec list say (1,2,3)
     
    A -->  INVITE (SDP-> audio 1 2 3) --> B      ( B supports  4, 5,6)
    A <--  20

Fred Stacey is out of the office.

2011-07-09T19:12:08

I will be out of the office starting  07/01/2011 and will not return until
07/11/2011.

I will be out of the office  From July 1 to July 10 inclusive.
If your inquiry is regarding Mitel AnyWare, please direct to
mitel_anyware_sales< at >mitel.com.
If your inquiry is regarding MICD or the Mitel Service Provider Program,
please direct to Andrew Moses (andrew_moses< at >mitel.com)

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

draft-jennings-sip-dtls: shouldn't it define ;transport=dccp ?

Iñaki Baz Castillo — 2011-07-08T16:53:04

Hi, draft-jennings-sip-dtls defines:

- SIP over DTLS over UDP   => Via transport: "DTLS-UDP"
- SIP over DTLS over DCCP => Via transport: "DTLS-DCCP"
- SIP over DCCP                 => Via transport: "DCCP"

The draft just defines new BNF grammar for Via transport field, but
says nothing about SIP URI ;transport param.
IMHO the draft MUST define a new value "dccp" for ;transport param.

Regards,

Difference between B2BUA and Proxy

Leon Li — 2011-06-23T01:40:55

Hi,

I just would like to clarify the difference between B2BUA and proxy in SIP. For example,


1.       From SIP point view

2.       From service point view

3.       From an endpoints view, if any

Regards
Leon

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

Hakiri Akram — 2011-05-31T20:44:27

Hi,
Did someone have an idea about an implementation of SIP extension for 
QoS support in DiffServ.

thanks.

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

Test, please ignore

Dean Willis — 2011-06-01T17:41:35

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