rfc-editor | 5 Jan 21:28 2004

RFC 3665 on Session Initiation Protocol (SIP) Basic Call Flow Examples


A new Request for Comments is now available in online RFC libraries.

        BCP 75
        RFC 3665

        Title:      Session Initiation Protocol (SIP) Basic Call Flow
                    Examples
        Author(s):  A. Johnston, S. Donovan, R. Sparks, C. Cunningham,
                    K. Summers
        Status:     Best Current Practice
        Date:       December 2003
        Mailbox:    alan.johnston <at> mci.com, sdonovan <at> dynamicsoft.com,
                    rsparks <at> dynamicsoft.com,
                    ccunningham <at> dynamicsoft.com,
                    kevin.summers <at> sonusnet.com
        Pages:      94
        Characters: 163159
        SeeAlso:    BCP 75

        I-D Tag:    draft-ietf-sipping-basic-call-flows-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3665.txt

This document gives examples of Session Initiation Protocol (SIP) call
flows.  Elements in these call flows include SIP User Agents and
Clients, SIP Proxy and Redirect Servers.  Scenarios include SIP
Registration and SIP session establishment.  Call flow diagrams and
message details are shown.  

(Continue reading)

rfc-editor | 5 Jan 21:30 2004

BCP 76, RFC 3666 on Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows


A new Request for Comments is now available in online RFC libraries.

        BCP 76
        RFC 3666

        Title:      Session Initiation Protocol (SIP)
                    Public Switched Telephone Network (PSTN) Call Flows
        Author(s):  A. Johnston, S. Donovan, R. Sparks, C. Cunningham,
                    K. Summers
        Status:     Best Current Practice
        Date:       December 2003
        Mailbox:    alan.johnston <at> mci.com, sdonovan <at> dynamicsoft.com,
                    rsparks <at> dynamicsoft.com,
                    ccunningham <at> dynamicsoft.com,
                    kevin.summers <at> sonusnet.com
        Pages:      118
        Characters: 200478
        SeeAlso:    BCP 76

        I-D Tag:    draft-ietf-sipping-pstn-call-flows-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3666.txt

This document contains best current practice examples of Session
Initiation Protocol (SIP) call flows showing interworking with the
Public Switched Telephone Network (PSTN).  Elements in these call
flows include SIP User Agents, SIP Proxy Servers, and PSTN
Gateways.  Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to
PSTN via SIP.  PSTN telephony protocols are illustrated using ISDN
(Continue reading)

Peter Lewis | 7 Jan 12:08 2004
Picon

WiFi Voice Conference - Paris

The WiFi Voice Conference will stand in Paris next May 25 to 28, 2004.
QoS, security, roaming, interoperability, architectures : distinguished experts
and key players in the field will address these questions with detailed and
technical explanations.
 
More details at:
http://www.upperside.fr/wifivoice04/wifivoice04intro.htm
Internet-Drafts | 7 Jan 15:22 2004
Picon

I-D ACTION:draft-ietf-sipping-3pcc-06.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           : Best Current Practices for Third Party Call
                          Control in the Session Initiation Protocol
	Author(s)	: J. Rosenberg, J. Peterson, H. Schulzrinne, 
                          G. Camarillo
	Filename	: draft-ietf-sipping-3pcc-06.txt
	Pages		: 32
	Date		: 2004-1-6
	
Third party call control refers to the ability of one entity to create
a call in which communications is actually between other parties. Third
party call control is possible using the mechanisms specified within
the Session Initiation Protocol (SIP). However, there are several
possible approaches, each with different benefits and drawbacks. This
document discusses best current practices for the usage of the SIP for
third party call control.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-3pcc-06.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.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-3pcc-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 135 bytes
Attachment (draft-ietf-sipping-3pcc-06.txt): message/external-body, 67 bytes
Szelényi Csaba | 7 Jan 15:43 2004
Picon

Completing URIs with port

Hi,

According to RFC3261 chapter 19.1.4 two URIs are not the same if one of them contains no port description and
the other one does contain the default port. E.g.:

   sip:bob <at> biloxi.com                   (can resolve to different ports)
   sip:bob <at> biloxi.com:5060

The CISCO 7960 completes the received URI with the ':5060' string in the following cases:
 - when the Contact URI is used as Request-URI in the next request (e.g. in case of redirection)
 - when the Record-Route is copied to the Route header in case of loose routing.

Is it legal? IMHO it is not, but I would like to be sure.

Thank you very mush for any input in advance!

Regards,

Szelényi Csaba
T-Systems RIC
mailto:Csaba.Szelenyi <at> t-systems.co.hu
+36 1 456 5507
+36 20 477 7778

_______________________________________________
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

Brett Tate | 7 Jan 19:40 2004

RE: Completing URIs with port

> According to RFC3261 chapter 19.1.4 two URIs are not the same 
> if one of them contains no port description and the other one 
> does contain the default port. E.g.:
> 
>    sip:bob <at> biloxi.com        (can resolve to different ports)
>    sip:bob <at> biloxi.com:5060
> 
> The CISCO 7960 completes the received URI with the ':5060' 
> string in the following cases:
>  - when the Contact URI is used as Request-URI in the next 
> request (e.g. in case of redirection)
>  - when the Record-Route is copied to the Route header in 
> case of loose routing.
> 
> Is it legal?

Within rfc2543, sip:bob <at> biloxi.com and
sip:bob <at> biloxi.com:5060 were considered equivalent.
Within rfc3261, they are no longer considered equivalent.
This is one of the various non backward compatibilities.

Because the adding of an extraneous port can break 
rfc3263 functionality within your example, you should
inquire when the product intends to become rfc3261
compliant concerning not extraneously adding port 5060.

_______________________________________________
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

Rohan Mahy | 8 Jan 00:19 2004
Picon

Re: Completing URIs with port

The Cisco 7960 does not claim to be fully RFC-3261 compliant.

thanks,
-rohan

On Wednesday, January 7, 2004, at 06:43 AM, Szelényi Csaba wrote:

> Hi,
>
> According to RFC3261 chapter 19.1.4 two URIs are not the same if one 
> of them contains no port description and the other one does contain 
> the default port. E.g.:
>
>    sip:bob <at> biloxi.com                   (can resolve to different 
> ports)
>    sip:bob <at> biloxi.com:5060
>
> The CISCO 7960 completes the received URI with the ':5060' string in 
> the following cases:
>  - when the Contact URI is used as Request-URI in the next request 
> (e.g. in case of redirection)
>  - when the Record-Route is copied to the Route header in case of 
> loose routing.
>
> Is it legal? IMHO it is not, but I would like to be sure.
>
> Thank you very mush for any input in advance!
>
> Regards,
>
> Szelényi Csaba
> T-Systems RIC
> mailto:Csaba.Szelenyi <at> t-systems.co.hu
> +36 1 456 5507
> +36 20 477 7778
>
>
> _______________________________________________
> 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

_______________________________________________
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

Banibrata Dutta | 8 Jan 07:43 2004
Picon

any info about "push-to-talk" service using SIP

hi,

i've gone thru few old posts about the push-to-talk service
that i could find via google, and it the idea that i got was
it's "just another service" and need not be discussed on the
mailing list!! also, another view was that, the service itself
is not properly defined.

wanted to know if these 2 view-points have changed since then?
has there been any effort to standardize the implementation,
or definition of this service w.r.t. SIP ?

push-to-talk, as applicable to mobile devices (i.e.
the thing i am interested in), is a half-duplex mode of
communication where a mobile user can push-a-special-button
(keep it pressed) and after a go-ahead signal (i.e. after
seizing control of the floor) can speak out. this he does
after selecting one particular individual or a group in
his/her buddy-list. buddy-list is just like in case of 
text IM clients, which may be provisioned off-line/on-line.
the addressed party, i.e. individual or group will hear
what the originator said, via their spearker-phone mode
enabled mobile devices, if they are available and connected,
else not. i.e. a best effort delivery. this is like the
walkie-talkies. only one person can have floor-control at
a time. while a floor is under control of an individual,
others can only listen, but cannot speak. they must wait
for their turn.

having given this rough description of the service, may i
know, where we are ? i.e. any standardization / draft making
effort underway (current or expired or planned) ??

another thing that i am interested in finding out is, what 
role can SIP play in this, given the fact that the target
network is basically GSM/GPRS network, and not a pure SIP 
network?

thanks & regards,
Banibrata Dutta
  Hewlett-Packard ISO Pvt. Ltd,
  29, Cunningham Road,
  Bangalore - 560052, India.
  Tel: +91-80-2051796

_______________________________________________
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

Garland Sharratt | 8 Jan 08:01 2004

RE: any info about "push-to-talk" service using SIP

The Open Mobile Alliance (www.openmobilealliance.org) has a large
standardization effort underway for PTT.  The project is called POC,
Push-to-talk Over Cellular.  They are using SIP over the data channel.

Regards,

Garland

-----Original Message-----
From: sipping-admin <at> ietf.org [mailto:sipping-admin <at> ietf.org]On Behalf Of
Banibrata Dutta
Sent: Wednesday, January 07, 2004 22:44
To: Sipping Mailing-List
Subject: [Sipping] any info about "push-to-talk" service using SIP

hi,

i've gone thru few old posts about the push-to-talk service
that i could find via google, and it the idea that i got was
it's "just another service" and need not be discussed on the
mailing list!! also, another view was that, the service itself
is not properly defined.

wanted to know if these 2 view-points have changed since then?
has there been any effort to standardize the implementation,
or definition of this service w.r.t. SIP ?

push-to-talk, as applicable to mobile devices (i.e.
the thing i am interested in), is a half-duplex mode of
communication where a mobile user can push-a-special-button
(keep it pressed) and after a go-ahead signal (i.e. after
seizing control of the floor) can speak out. this he does
after selecting one particular individual or a group in
his/her buddy-list. buddy-list is just like in case of
text IM clients, which may be provisioned off-line/on-line.
the addressed party, i.e. individual or group will hear
what the originator said, via their spearker-phone mode
enabled mobile devices, if they are available and connected,
else not. i.e. a best effort delivery. this is like the
walkie-talkies. only one person can have floor-control at
a time. while a floor is under control of an individual,
others can only listen, but cannot speak. they must wait
for their turn.

having given this rough description of the service, may i
know, where we are ? i.e. any standardization / draft making
effort underway (current or expired or planned) ??

another thing that i am interested in finding out is, what
role can SIP play in this, given the fact that the target
network is basically GSM/GPRS network, and not a pure SIP
network?

thanks & regards,
Banibrata Dutta
  Hewlett-Packard ISO Pvt. Ltd,
  29, Cunningham Road,
  Bangalore - 560052, India.
  Tel: +91-80-2051796

_______________________________________________
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

_______________________________________________
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

Pete Cordell | 8 Jan 11:13 2004

Re: Problem with reg-event that needs immediate fix

Jonathan, Cullen,

One concern I have about many XML schemas defined in this space is how they
will be extended for subsequent versions.  Has a strategy been defined?

The reason I mention it is that I read an article on xml.com about
versioning (http://www.xml.com/pub/a/2003/12/03/versioning.html) and it
proposes adding additional syntax to a schema to allow an instance
conforming to a new version of a schema to be correctly validated against a
previous version of the schema.

It uses <xs:any namespace="##other"> (the form used in a lot of the SIP
schemas) to allow for 'third party' extensions.

But, to allow the schema to be extended with new elements it suggests the
following format (I've tried to mark the relevant bits with ****s):

<s:complexType name="CallbackType">
 <s:sequence>
 <s:element name="callbackLocation" type="s:anyURI"
minOccurs="1" maxOccurs="1"/>
**** <s:element name="Extension" type="wscb:ExtensionType"
            minOccurs="0" maxOccurs="1"/>*****
 <s:any processContents="lax" minOccurs="0"
maxOccurs="unbounded" namespace="##other"/>
 </s:sequence>
 <s:anyAttribute/>
</s:complexType>

*****
<s:complexType name="ExtensionType">
 <s:sequence>
 <s:any processContents="lax" minOccurs="1"
maxOccurs="unbounded" namespace="##targetnamespace"/>
 </s:sequence>
******

 <s:anyAttribute/>
</s:complexType>

If an extension is added to the schema, (I think!) it would become:

<s:complexType name="CallbackType">
 <s:sequence>
 <s:element name="callbackLocation" type="s:anyURI"
minOccurs="1" maxOccurs="1"/>
<s:element name="Extension" type=******"wscb:MyExtension"*****
            minOccurs="0" maxOccurs="1"/>
 <s:any processContents="lax" minOccurs="0"
maxOccurs="unbounded" namespace="##other"/>
 </s:sequence>
 <s:anyAttribute/>
</s:complexType>

*****
<s:complexType name="MyExtension">
 <s:sequence>
  <s:element name="myNewElement" type="xs:string"/>
<s:element name="Extension" type="wscb:ExtensionType"
            minOccurs="0" maxOccurs="1"/>
</s:sequence>
</s:complexType>
*******

<s:complexType name="ExtensionType">
 <s:sequence>
 <s:any processContents="lax" minOccurs="1"
maxOccurs="unbounded" namespace="##targetnamespace"/>
 </s:sequence>
 <s:anyAttribute/>
</s:complexType>

An alternative would be to define all new extensions in a separate
namespace.  However, this becomes a bit imprecise because its not easy to
say where the new material plugs into the original schema.

So my question is this an issue, or have I just not found the right
document?!

Happy New Year,

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete <at> tech-know-ware.com
http://www.tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: "Cullen Jennings" <fluffy <at> cisco.com>
To: "Jonathan Rosenberg" <jdrosen <at> dynamicsoft.com>; "sipping"
<sipping <at> ietf.org>
Sent: 30 December 2003 17:34
Subject: Re: [Sipping] Problem with reg-event that needs immediate fix

>
> I would prefer to change the Schema to be right for this things we know
are
> coming even if that broke backwards compatibility.
>
> The more I look at the schema, I think the whole the things could be
> structured a little better for extensibility. I had the same comment on
some
> of the other schema that have been in sipish drafts. We should probably
make
> this part of our NITS review.
>
> Cullen
>
> On 12/18/03 9:13 AM, "Jonathan Rosenberg" <jdrosen <at> dynamicsoft.com> wrote:
>
> > While implementing the sipping reg-event draft, we ran into a serious
> > technical problem.
> >
> > The problem is that the specification has not left sufficient room for
> > extensibility within the XML schema. It allows for new information to
> > be added to the <registration> element (which describes the AOR), but
> > does not allow any additional information to be provided about a
> > contact. We ran into this problem because we needed to add path
> > information (ala rfc 3327) to the notifications, but this information
> > is per contact. There is no way to do this with the current
specification.
> >
> > The essence of the problem is that the contact element has, as
> > content, the actual URI. This makes it difficult to add other
> > information about the contact. A better approach would have been to
> > make the contact element a complex type, which would include an
> > element called <uri> that contains the uri.
> >
> > For example, today we have:
> >
> > <?xml version="1.0"?>
> >   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
> >                version="1" state="partial">
> >     <registration aor="sip:joe <at> bar.com" id="a7" state="active">
> >       <contact id="76" state="active" event="registered"
> >                duration-registered="0">sip:joe <at> pc34.bar.com</contact>
> >     </registration>
> >   </reginfo>
> >
> > whereas it ought to have been:
> >
> > <?xml version="1.0"?>
> >   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
> >                version="1" state="partial">
> >     <registration aor="sip:joe <at> bar.com" id="a7" state="active">
> >       <contact id="76" state="active" event="registered"
> >                duration-registered="0">
> >                   <uri>sip:joe <at> pc34.bar.com</uri>
> >       </contact>
> >     </registration>
> >   </reginfo>
> >
> >
> > The schema for the contact element could then allow for other children
> > in other namespaces, giving us the needed extensibility.
> >
> > Unfortunately, there is other per-contact data we might want to add in
> > the not-too-distant future, such as callee-caps information. That kind
> > of data would be very useful for presence applications, where the
> > presence server could obtain it from the registrar using reg-event.
> >
> > I believe that this problem is significant enough that we should try
> > and address it during auth48. For those of you not familiar with it,
> > auth48 is a brief period just before publication of the actual RFC
> > where the author can correct typos or minor other problems. It is
> > possible, with AD approval, to make more substantive changes as I am
> > suggesting (and indeed I already ran this by Allison and she is OK).
> > Of course, I still need group consensus on any change. So, here is my
> > proposal.
> >
> > PROPOSAL
> >
> > My proposal for fixing this, as outlined above, is to modify the XML
> > schema. The <contact> element will instead become a complex type. It
> > will have, as children, a sequence of <uri> followed by an optional
> > element from any other namespace. The <uri> element will contain the
> > actual contact URI.
> >
> > Unfortunately, this proposed solution above is not backwards
> > compatible with the current draft.
> >
> > I considered other solutions as well:
> >
> >
> > ALTERNATE 1
> >
> > Modify the schema to allow attributes in the contact element from
> > other namespaces. Adds some extensibility, but is very bad for more
> > complex data, such as path or callee-cap data. Using attributes for
> > that data will require us to define a lot of structure within each
> > attribute. This approach is backwards compatible, but not forwards
> > compatible. That is, an implementation compliant to the schema before
> > this change would reject documents created by an implementation
> > compliant to the schema after the change.
> >
> > ALTERNATE 2
> >
> > Modify the schema to contain a new element, child to the
> > <registration> element. This element would be called "alt-contact",
> > and would be defined as I suggest above for contact. Whenever new
> > information is needed about a contact, the "alt-contact" element would
> > be present, and contain that extension data. The document would also
> > still contain a contact element, repeating the URI and other
> > attributes. This would provide forwards and backwards compatibility,
> > at the expense of a horrible hack that would repeat a lot of
> > information in the document.
> >
> >
> > I found neither of the two alternatives very palatable, which is why
> > my proposal is to fix this now, and do it properly, while we still can.
> >
> > Please provide input on the proposal ASAP. I'd like to come to
> > consensus in the next week or so (before everyone disappears for
> > vacations).
> >
> > Thanks,
> > Jonathan R.
>
>
> _______________________________________________
> 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

_______________________________________________
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


Gmane