headers
Ram Dantu | 3 Oct 2005 06:11
Picon

IEEE Network Special Issue on VoIP Security

Hello everyone--

We plan to edit IEEE Network special issue on VoIP Security.
We invite submissions for this special issue and the due date is October 15, 2005. See the following link for
more details
(http://www.comsoc.org/pubs/net/ntwrk/cfpnetwork3Q06.htm).

We appreciate if you can forward this message to  
the people interested in VoIP and security.

Thanks
Guest Editors

Ram Dantu, University of North Texas
Dipak Ghosal, University of California, Davis
Henning Schulzrinne, Columbia University

NOTE: IEEE Network was the number two most-cited journal in electrical and
electronics engineering, number one cited journal in telecommunications,
and the number two cited journal in computer science hardware
and architecture, and computer science information systems in 2003,
according to the annual Journal  Citation Report (2003 edition) published
by the Institute for Scientific Information.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Markus.Isomaki | 3 Oct 2005 13:55
Picon

draft-ietf-sipping-sos vs. draft-schulzrinne-sipping-service

Hi,

I noticed that draft-sipping-sos, which proposed a universal emergency URI, sip:sos <at> domain, has
expired a long time ago. Does this mean that this proposal has been abandoned in SIPPING? On the other hand I
noticed that there is a new draft-schulzrinne-sipping-service, which proposes a bit more generic URN
based method, i.e. the emergency calls would be identified as urn:service:sos. Is this considered as a
replacement to the old sos-URI? 

I believe we need something to identify emergency calls (globally) and I would be happy to go ahead with the
URN based model. But I since the URN mechanism is not SIP-specific, I'm not sure where it belongs in the IETF
currently, e.g. is SIPPING WG taking it.

Regards,
	Markus 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 8 comments |
headers
Henning Schulzrinne | 3 Oct 2005 15:32

Re: draft-ietf-sipping-sos vs. draft-schulzrinne-sipping-service

Markus,

I was hoping this topic would get a bit more discussion than it has, so 
thanks for raising the issue.

As you correctly surmise, the 'service' draft is meant as the more 
generalized version, also solving some of the problems that the tel URI 
has in similar situations and avoiding the overloading of the user part 
of the SIP URI. The sos <at>  also has the disadvantage that either routing 
is "late" (at the 'home' proxy) or deviates from normal resolution 
practices (if done at the outbound proxy).

While motivated by 911/112 emergency services, the URN mechanism also 
works for the other N11 services (in the US), e.g., directory 
assistance, repair or general government services (311 in some cities). 
While I have not specified this to avoid getting too side-tracked, one 
can also imagine extending this to other commercial services, e.g., 
taxi, pizza or towing.

The disadvantage of the new scheme is deployability: Like tel URIs, the 
outbound proxy needs to understand the scheme.

Also, while the sos <at>  mechanism doesn't require any special client 
support, the service URN obviously does.

I obviously agree with you that we need something - and preferably 
before we replicate, on a global scale, the mess of the current 
emergency call identifier system.

Given that the IPTEL group is defunct, the number of venues to discuss
(Continue reading)

Permalink | Reply | 7 comments |
headers
Paul Kyzivat | 3 Oct 2005 16:44
Picon
Favicon

Re: Re: draft-ietf-sipping-sos vs. draft-schulzrinne-sipping-service

Henning,

Henning Schulzrinne wrote:

> While motivated by 911/112 emergency services, the URN mechanism also 
> works for the other N11 services (in the US), e.g., directory 
> assistance, repair or general government services (311 in some cities). 
> While I have not specified this to avoid getting too side-tracked, one 
> can also imagine extending this to other commercial services, e.g., 
> taxi, pizza or towing.

I agree that it seems quite applicable to all of these.

There is one somewhat more problematic case that I would be interested 
in getting your opinion on: "operator" services.

These seem to fall into at least two categories:

- simply requesting an operator, e.g. by dialing "0" or "00".

   The service URN approach seems perfectly suitable for this

- dialing "0nnn..." to request operator assistance with the
   placing of a call to a specified target. In this case, either
   the operator assistance can be viewed as a modifier or route to a
   specified target, or else it may be viewed that the operator
   is the target and some extra digits are a parameter to the
   operator.

   The applicability of the service URN to this case seems less clear.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Henning Schulzrinne | 3 Oct 2005 17:52

Re: Re: draft-ietf-sipping-sos vs. draft-schulzrinne-sipping-service

Paul:

The basic problem for service identifiers is that they essentially 
involve a mapping of

(identifier) + (context)

to a "real" (SIP) URI, where context can be "outbound proxy used", 
"geographic location of caller" or "service provider I'm with", among 
others.

I'm not quite sure that the second issue you raise is actually a service 
identifier as such. It seems much more closely related to the caller 
preferences work or possibly the service routing work, as it relates how 
a call is handled or routed, namely via an operator service. If that 
approach does work, it would obviously also work for non-numeric 
identifiers. Your "operator call for number N" does not seem to me 
fundamentally different from "call via a translation service" or "call 
via a telephone relay operator".

Henning

> I agree that it seems quite applicable to all of these.
> 
> There is one somewhat more problematic case that I would be interested 
> in getting your opinion on: "operator" services.
> 
> These seem to fall into at least two categories:
> 
> - simply requesting an operator, e.g. by dialing "0" or "00".
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Kyzivat | 3 Oct 2005 18:35
Picon
Favicon

Re: Re: draft-ietf-sipping-sos vs. draft-schulzrinne-sipping-service


Henning Schulzrinne wrote:
> Paul:
> 
> The basic problem for service identifiers is that they essentially 
> involve a mapping of
> 
> (identifier) + (context)
> 
> to a "real" (SIP) URI, where context can be "outbound proxy used", 
> "geographic location of caller" or "service provider I'm with", among 
> others.
> 
> I'm not quite sure that the second issue you raise is actually a service 
> identifier as such. It seems much more closely related to the caller 
> preferences work or possibly the service routing work, as it relates how 
> a call is handled or routed, namely via an operator service. If that 
> approach does work, it would obviously also work for non-numeric 
> identifiers. Your "operator call for number N" does not seem to me 
> fundamentally different from "call via a translation service" or "call 
> via a telephone relay operator".

I think that depends on how you interpret and extrapolate the service.

If you view it as "apply operator services to the call to this target" 
then I agree with you.

But if you view it as "call the operator and provide this hint about an 
intended target, that might be ignored, adjusted, or reinterpretted by 
the operator", then that model doesn't fit.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Henning Schulzrinne | 3 Oct 2005 18:43

Re: Re: draft-ietf-sipping-sos vs. draft-schulzrinne-sipping-service

If it is a hint, then maybe this fit better into an informational header 
rather than trying to squeeze this into an identifier. The third model 
is that of a "domain of interpretation", which is the user identifier. 
In other words,

0113512345 <at> operator.myisp.com

allows local interpretation by a well-defined party.

As interesting as this problem is, I'd also appreciate comments on the 
problems the draft *is* trying to solve :-)

> 
> I think that depends on how you interpret and extrapolate the service.
> 
> If you view it as "apply operator services to the call to this target" 
> then I agree with you.
> 
> But if you view it as "call the operator and provide this hint about an 
> intended target, that might be ignored, adjusted, or reinterpretted by 
> the operator", then that model doesn't fit.
> 
> I don't actually know which is the proper interpretation.
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henry Sinnreich | 4 Oct 2005 03:06

draft-stein-great-00.txt

	Title		: Great Real-Time Problem Statement
	Author(s)	: Y. Stein
	Filename	: draft-stein-great-00.txt
	Pages		: 11
	Date		: 2005-9-30
http://www.ietf.org/internet-drafts/draft-stein-great-00.txt 

This document seems to be a reflection of all the sour grapes about the
Internet, VoIP, QoS and reliability and makes one wonder how come that so
many public VoIP services work well and have an ever growing customer base.

No evidence is provided to support any of the statements.

If the author's intent is to address the facts, a white paper for the
marekting department may be the better place for such a memo.

Thanks, 

Henry Sinnreich
Pulver.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 2 comments |
headers
Internet-Drafts | 4 Oct 2005 16:50
Picon
Favicon

I-D ACTION:draft-ietf-sipping-gruu-reg-event-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Reg Event Package Extension for GRUUs
	Author(s)	: P. Kyzivat
	Filename	: draft-ietf-sipping-gruu-reg-event-00.txt
	Pages		: 12
	Date		: 2005-10-4
	
   This draft defines an extension to RFC 3680 [1] for representing the
   GRUU associated with a Contact.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-gruu-reg-event-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-gruu-reg-event-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Francois Mule | 4 Oct 2005 22:37
Favicon

RE: Re: WGLC: SIP service quality reporting

Fixing some formatting issues:
> >    SessionDesc=PT:0 PD:G.711 SR:8000 FD:20 FPP:2 PLC:3 SSUP:on
                           ^^^^^
And the comment should have been more precise as well:
If the payload type is PT==0, the payload description must be PD:PCMU.

> PCMU. Please use the encoding name registered with IANA. What concerns
> me is that the BNF does not provide any means to enforce the
> requirements: could any MUST requirement be added to provide better
> guidance to implementers?

Jean-François

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |

Gmane