Subject: Re: [Sipping] Push-To-Talk with SIP

From: Rohan Mahy <[email-masked]>
Date: Tue, 20 May 2003 13:15:15 -0700

Hi,

Push to talk can be implemented by merely setting up a session between 
the speaker and the target when the UA becomes available and leaving 
the session open, but only sending audio media over that session when a 
button is pushed.  The session can be verified for liveness by using 
the session-timer, and the target suddenly reappearing after an absence 
can be detected using the registration package.  Perhaps someone could 
write a draft describing this usage?

thanks,
-rohan

On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote:

> Hello,
>  
> Nokia, Siemens and Ericsson have announced that they are developing a 
> push-to-talk application for GSM networks with GPRS and for future 3G 
> networks. They want to use SIP for signaling but I couldn't find any 
> more detailed information.
>  
> Does someone of you know some detail about the PTT signaling with SIP?
> Do they care about arbitration if two people want to talk to the same 
> group at the same time? Are there some drafts or discussions about 
> this topics?
>  
> regards,
> thomas lee.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Tue, 20 May 2003 19:20:32 -0400

Rohan,
though this method has been mentioned before it does have issues like 
keeping a session active in all billing entities as well
as on UAs. This becomes an issue especially when billing agents may not be 
in media path (in the SIP implementation).
In addition, this would mean that end-phones would necessarily have to be 
able to maintain atleast two calls (one PTT mode,
and the other normal mode ). In addition, needless to mention, in PTT any 
one can burst talk to any other person within a particular
group - which has implications , for example, if A is already 'PTTing' 
with B and C sends a PTT to A, how does A handle the call if 
its already in 'session' ? Another call ? Adhoc mix ?  etc. etc.

For this very reason, some people are also considering 'session less' 
approaches as well, which have their own issues 
wrt. voice packet continuity.

It may be a good idea to discuss an approach and its associated benefits 
and the requirements.

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860 

Rohan Mahy <[email-masked]>
Sent by: [email-masked]
05/20/2003 04:15 PM

        To:     <[email-masked]>
        cc:     <[email-masked]>
        Subject:        Re: [Sipping] Push-To-Talk with SIP

Hi,

thanks,
-rohan

---

From: "Gonzalo Camarillo Gonzalez (LMF)" <[email-masked]>
Date: Wed, 21 May 2003 04:46:42 +0200

Rohan,

a push-to-talk service would include some form of floor control as well.

Gonzalo

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Tuesday, May 20, 2003 11:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Push-To-Talk with SIP

Hi,

thanks,
-rohan

---

From: [email-masked]
Date: Wed, 21 May 2003 09:07:43 +0530

Is there a definition what this service means? I have looked at Comverse,
Winphoria, Comworks implementation and that is more of Buddylist based
feature where I can see who is available and speak accordingly. If this is
what is Push-To-Talk, I am not sure if we need a new draft.  May be we need
to define this functionality to start with before someone can come with a
draft.
Thanks,
Subir

"Gonzalo Camarillo Gonzalez (LMF)" <[email-masked]> on
05/21/2003 08:16:42 AM

To:   "'Rohan Mahy'" <[email-masked]>, [email-masked]
cc:   [email-masked] (bcc: Subir Saha/HSSBLR)

Subject:  RE: [Sipping] Push-To-Talk with SIP

Rohan,

Gonzalo

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Tuesday, May 20, 2003 11:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Push-To-Talk with SIP

Hi,

thanks,
-rohan

---

From: "Gonzalo Camarillo Gonzalez (LMF)" <[email-masked]>
Date: Wed, 21 May 2003 05:50:46 +0200

Subir,

as far as I understand, "Push-To-Talk" is a service offered by a specific company. Other companies offering that type of service need to call it something different. All those services have common functionality, but they have differences as well. There is not *a* PTT service definition (right now).

Gonzalo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 21, 2003 6:38 AM
To: Gonzalo Camarillo Gonzalez (LMF)
Cc: 'Rohan Mahy'; [email-masked]; [email-masked]
Subject: RE: [Sipping] Push-To-Talk with SIP

Rohan,

Gonzalo

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Tuesday, May 20, 2003 11:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Push-To-Talk with SIP

Hi,

thanks,
-rohan

---

From: [email-masked]
Date: Wed, 21 May 2003 09:37:55 +0530

Gonzalo:
In that case, may be, we can start form here - trying to define a Push to
talk service and then see what is missing in SIP/SIMPLE to achive such
functionality!

Subir

05/21/2003 09:20:46 AM

To:   Subir Saha/HSSBLR
cc:   "'Rohan Mahy'" <[email-masked]>, [email-masked],
      [email-masked]

Subir,

as far as I understand, "Push-To-Talk" is a service offered by a specific
company. Other companies offering that type of service need to call it
something different. All those services have common functionality, but they
have differences as well. There is not *a* PTT service definition (right
now).

Gonzalo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 21, 2003 6:38 AM
To: Gonzalo Camarillo Gonzalez (LMF)
Cc: 'Rohan Mahy'; [email-masked]; [email-masked]
Subject: RE: [Sipping] Push-To-Talk with SIP

Rohan,

Gonzalo

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Tuesday, May 20, 2003 11:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Push-To-Talk with SIP

Hi,

thanks,
-rohan

---

From: [email-masked]
Date: Wed, 21 May 2003 15:52:36 +0300

Hi Rohan,

I think this is one way to look at the push to talk feature, but maybe not exactly "mainstream". Most of the push to talk services I'm aware of are similar to a walkie talkie service, where a group of people are participating, out of which only one at a time can send media to the others. "Requesting the floor" in this case is usually done with the "tangent" button.

So in my opinion, push to talk is a conference, with a specific type of conference and media policy associated with it. As such, I don't think it's the IETF's business to define those policies but provide tools for setting/manipulating them, which I guess the conference DT is already doing. 

	-Aki

 > From: ext Rohan Mahy [mailto:[email-masked]]
 > Sent: 20 May, 2003 23:15

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Wed, 21 May 2003 10:15:22 -0400

I think to avoid confusion, it may be better to reword this is a 'session 
less two way radio service',
with session less being the key item. I believe this was the original 
question of the poster.

Whether this particular approach makes sense to be done in SIP and 
especially in the purview of the IETF  is another question.

regds
arjun

[email-masked]
05/21/2003 08:52 AM

        To:     <[email-masked]>, <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: [Sipping] Push-To-Talk with SIP

Hi Rohan,

I think this is one way to look at the push to talk feature, but maybe not 
exactly "mainstream". Most of the push to talk services I'm aware of are 
similar to a walkie talkie service, where a group of people are 
participating, out of which only one at a time can send media to the 
others. "Requesting the floor" in this case is usually done with the 
"tangent" button.

So in my opinion, push to talk is a conference, with a specific type of 
conference and media policy associated with it. As such, I don't think 
it's the IETF's business to define those policies but provide tools for 
setting/manipulating them, which I guess the conference DT is already 
doing. 

                 -Aki

---

From: [email-masked]
Date: Thu, 22 May 2003 12:32:26 +0300

Hi Arjun,

I don't really understand what you mean by 'session less', could you elaborate a bit? Do you mean to say there is no application state maintained at the endpoints? 

And to me, the original question seemed to be whether there have been any drafts or discussions w.r.t. push to talk and SIP in the IETF. And the enswer to that would have to be no, but the conferencing work in SIPPING seems to be covering related issues, e.g., floor control, and media policy.

Regards,	
Aki

 > From: ext Arjun Roychowdhury [mailto:[email-masked]]
 > Sent: 21 May, 2003 17:15
 > To: Niemi Aki (NMP/Helsinki)
 > Cc: [email-masked]; [email-masked]; [email-masked];
 > [email-masked]
 >  > Sipping mailing list  
 > https://www1.ietf.org/mailman/listinfo/sipping

---

From: [email-masked]
Date: Thu, 22 May 2003 08:18:27 -0400

Aki,
By 'session less' I mean not having an INVITE-OK-ACK to actually establish 
the call before you could talk. Application state would be maintained
during one 'push-release' operation and forgotten after that (except for 
the administrative states like which was the gruop set I was talking to).

Different algorithms have been suggested for this 'voice over IM' => some 
are also patented @ the uspto (I think someone had posted the patent no.
in the impp archive some time ago)

Anyway, therefore, I realize this may not be something that the ietf sip 
grp wants to take up unless there is a compelling reason 
go into into this 2 way radio service. With respect to the original Q, I 
agree that one could conceptualize that a call in session with RTP
bursts and conferencing thrown in could look like a '2 way radio service' 
= but due to the nature of its persistance of state for a much longer
time than currently known implementations not using SIP, the charging 
model and complexities would likely not be the same, for what ever its 
worth.

regds
arjun

[email-masked]
05/22/2003 05:32 AM

        To:     <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>
        Subject:        RE: [Sipping] Push-To-Talk with SIP

Hi Arjun,

I don't really understand what you mean by 'session less', could you 
elaborate a bit? Do you mean to say there is no application state 
maintained at the endpoints? 

And to me, the original question seemed to be whether there have been any 
drafts or discussions w.r.t. push to talk and SIP in the IETF. And the 
enswer to that would have to be no, but the conferencing work in SIPPING 
seems to be covering related issues, e.g., floor control, and media 
policy.

Regards, 
Aki

---

From: [email-masked]
Date: Thu, 22 May 2003 17:50:27 +0300

Arjun,

Judging from your answer (especially the 'voice over IM' part) I think we might have been talking about two different services under the same name. Likewise, the fact that in this thread already there have been at least three different interpretations of what a push to talk service means for SIP, makes me wonder whether this is a worthwhile debate to have in the IETF at all. I.e., let the market do the branding game. ;-)

We should come back when there is a specific SIP issue to address (whatever the service), IMHO.

Cheers,
Aki

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 22 May, 2003 15:18
To: Niemi Aki (NMP/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sipping] Push-To-Talk with SIP

Aki, 
By 'session less' I mean not having an INVITE-OK-ACK to actually establish the call before you could talk. Application state would be maintained 
during one 'push-release' operation and forgotten after that (except for the administrative states like which was the gruop set I was talking to). 

Different algorithms have been suggested for this 'voice over IM' => some are also patented @ the uspto (I think someone had posted the patent no. 
in the impp archive some time ago) 

Anyway, therefore, I realize this may not be something that the ietf sip grp wants to take up unless there is a compelling reason 
go into into this 2 way radio service. With respect to the original Q, I agree that one could conceptualize that a call in session with RTP 
bursts and conferencing thrown in could look like a '2 way radio service' = but due to the nature of its persistance of state for a much longer 
time than currently known implementations not using SIP, the charging model and complexities would likely not be the same, for what ever its worth. 

regds 
arjun 

[email-masked] 
        
        To:        <[email-masked]> 
        cc:        <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
        Subject:        RE: [Sipping] Push-To-Talk with SIP

Hi Arjun,

Regards,                 
Aki

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Fri, 23 May 2003 09:27:03 -0400

Markus, I agree.
Which is why I referred to the service as '2 way radio' and not PTT , 
since that term is somewhat synonymous to a particular
implementation methodology.

Aki and I discussed this in offline e-mails and concluded for this very 
reason that it doesnt make sense to continue
this thread , at least for now, in the IETF :-)

regds
arjun

<[email-masked]>
05/23/2003 09:20 AM

        To:     [email-masked], <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
        Subject:        RE: [Sipping] Push-To-Talk with SIP

Hi Arjun,
 
I guess there are several ways to implement "push to talk" type of 
service. It depends what kind of requirements you have. Sending voice 
clips inside IM is one type of service, but if you want to do multi-party 
communication and floor control, that may not be the best way. Another way 
is to model the communication as conferences (as in SIPPING Conferencing 
Framework), in which case you will use INVITE-OK-ACK to join and BYE to 
leave. But as said, there are many ways to implement the actual service 
using SIP, SIMPLE, conferencing specifications, floor control etc. that it 
does not seem something that really fits into IETF scope. Of course IETF 
should continue developing the basic building blocks such as messaging and 
conferencing related specifications.
 
Markus
-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 22 May, 2003 15:18
To: Niemi Aki (NMP/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Subject: RE: [Sipping] Push-To-Talk with SIP

Aki, 

regds 
arjun 

[email-masked] 
        
        To:        <[email-masked]> 
        cc:        <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]> 
        Subject:        RE: [Sipping] Push-To-Talk with SIP

Hi Arjun,

Regards, 
Aki

---

From: [email-masked]
Date: Fri, 23 May 2003 16:20:45 +0300

Hi Arjun,
 
I guess there are several ways to implement "push to talk" type of service. It depends what kind of requirements you have. Sending voice clips inside IM is one type of service, but if you want to do multi-party communication and floor control, that may not be the best way. Another way is to model the communication as conferences (as in SIPPING Conferencing Framework), in which case you will use INVITE-OK-ACK to join and BYE to leave. But as said, there are many ways to implement the actual service using SIP, SIMPLE, conferencing specifications, floor control etc. that it does not seem something that really fits into IETF scope. Of course IETF should continue developing the basic building blocks such as messaging and conferencing related specifications.
 
Markus

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 22 May, 2003 15:18
To: Niemi Aki (NMP/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sipping] Push-To-Talk with SIP

Aki, 

regds 
arjun 

	[email-masked] 

05/22/2003 05:32 AM 

        To:        <[email-masked]> 

Hi Arjun,

Regards,                 
Aki