headers
Jonathan Rosenberg | 1 Dec 2002 05:57

Re: [Simple] any SIP progress in devices?

This email belongs on sipping.

There are many drafts on these subjects. Here are some for starters:

http://www.jdrosen.net/papers/draft-rosenberg-sip-app-components-01.txt
http://www.jdrosen.net/papers/draft-rosenberg-sip-vxml-00.txt
http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-03.txt
http://www.ietf.org/internet-drafts/draft-vandyke-mscml-00.txt

I think the first will be most relevant to your question.

-Jonathan R.

Li Hua Tang wrote:
> Hi, all
> 
> I'd like to know how about SIP work on sessions involving in multiple
> devices and server resources. My interesting points includes how to
> exchange the events among devices, how to control Prompt Players, Text to
> Speech, and Speech Recognition Engines.
> 
> Thanks very much for your information.
> 
> Best regards,
> 
> Tang Lihua
> IBM China Research Lab.
> Email:  tanglih <at> cn.ibm.com
> 
> _______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ranjit Kumar Avasarala | 2 Dec 2002 06:42

RE: Re: [Simple] any SIP progress in devices?

Hi
   what is the status of the draft :
draft-rosenberg-sip-app-components-01.txt
 as it has expired.

 Thanks
 Ranjit

-----Original Message-----
From: sipping-admin <at> ietf.org [mailto:sipping-admin <at> ietf.org]On Behalf Of
Jonathan Rosenberg
Sent: Sunday, December 01, 2002 10:28 AM
To: Li Hua Tang
Cc: sipping <at> ietf.org
Subject: [Sipping] Re: [Simple] any SIP progress in devices?

This email belongs on sipping.

There are many drafts on these subjects. Here are some for starters:

http://www.jdrosen.net/papers/draft-rosenberg-sip-app-components-01.txt
http://www.jdrosen.net/papers/draft-rosenberg-sip-vxml-00.txt
http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-03.txt
http://www.ietf.org/internet-drafts/draft-vandyke-mscml-00.txt

I think the first will be most relevant to your question.

-Jonathan R.

Li Hua Tang wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Kyzivat | 2 Dec 2002 15:22
Picon
Favicon

Re: Re: Early media draft

My point is that the significance of the directionality should *not*, and need not, be context sensitive. 

	Paul

Christer Holmberg wrote:
> 
> Hi,
> 
> I think it also important to remember that in some cases "inactive" really does mean that we shall not pass
any media. Call hold is one example. So, now "inactive" would have a little different "meaning" depending
on the state of the call...
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Paul Kyzivat wrote:
> 
> > I don't have a problem discussing when it is/isn't appropriate to use inactive, or what the implications
of doing so are. But I do believe it is important to honor the intent of the directionality specifications.
> >
> > If you offer me sendrecv, but I answer you with inactive, then you should not send me anything. If that
results in clipping, so be it. While the stream is inactive, I may well not read from it at all. Depending on
the type of transport, if you write to it there could be a variety of different error conditions. (Of course
in the case of RTP, I still must read the RTCP, but that is all.)
> >
> >         Paul
> >
> > William Marshall wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kyzivat | 2 Dec 2002 21:20
Picon
Favicon

Re: Early media: a summary

Gonzalo,

I don't see how the changes you have made help solve the problem. As far as I can see, adding another attribute
simply makes the offer/answer handshake more complex without benefit.

The fundamental problem with the offer/answer protocol is that each side explicitly controls where it
will receive with each offer/answer exchange. There is never any guarantee that the answerer will
provide the same media address that was provided in a prior exchange. So when an endpoint wants to switch
from not-sending to sending, if it sends an offer and then begins sending media to the previously agreed to
address/port, there is no guarantee that the port in the answer will be the same, or that the media stream
might not forbid sending entirely.

Also, if there was previously a negotiation to permit sending but not intend to send, a new offer to change
the intention to permit sending may still be overtaken by media packets. To use this technique to avoid
clipping, the receiver would have to receive and present media even when it has been negotiated that the
sending doesn't intend to send. Hence the a:intention attribute doesn't seem to have any value.

If you assume that an endpoint will concurrently learn of the need to send and begin getting media, then
there is no solution to clipping other than establishing a media stream with sender and receiver prior to
that event. If the endpoint can separate those two events, and control when media will be available for
sending based on signalling feedback, then there are many other options available.

The typical telephone seems to fall somewhere between the two extremes. There is often some delay between
the indication that a call should be answered and the time when meaningful media becomes available to
send, but the delay is not coupled to signalling feedback. Whether the delay is long enough for signalling
to complete will vary based on network delays, the human factors of the device design, and human response
times. (How long does it take from off-hook until the phone is in position to speak into?) This should
*only* apply to devices directly associated with humans. Automated devices that *control* their media
should not enable it until signalling is complete.
(Continue reading)

Permalink | Reply | 3 comments |
headers
ysong | 3 Dec 2002 00:58
Favicon

Re: request history reqts and draft-levy-sip-diversion-04.txt


Hi,

It seems that the diversion information addressed in the sip-diversion
draft will be addressed by the request-history draft.
Also, the sip-diversion draft doesn't seem to be a SIPPING WG item.
Is the request-history draft (or its effort) intended to replace the
sip-diversion draft?

Thanks,
YoungSun

                                                                                                      
                    Francois-Xavier.Guitton <at>                                                           
                    alcatel.fr                      To:     sipping <at> ietf.org                          
                                                    cc:     (bcc: Youngsun Song/Telcordia)            
                    11/20/2002 04:23 AM             Subject:     [Sipping]                            
                                                    draft-levy-sip-diversion-04.txt                   

Dear Sipping members,

I made some research on the SIP mailing lists but I did not find any
reaction on the draft-levy-sip-diversion-04.txt draft.

Can you tell me if the SIP community is enthusiastic with this proposal ?
Is it largely under implementation ?

Regards,

François-Xavier Guitton./.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Gonzalo Camarillo | 3 Dec 2002 10:12
Picon
Picon

Re: Early media: a summary

Paul,

> Also, if there was previously a negotiation to permit sending but not 
>intend to send, a new offer to change the intention to permit sending 
>may still be overtaken by media packets. To use this technique to avoid 
>clipping, the receiver would have to receive and present media even when 
>it has been negotiated that the sending doesn't intend to send. Hence 
>the a:intention attribute doesn't seem to have any value.

The fact that any SIP signal can be overtaken my the media is something
unavoidable we have to live with. However, the a:intention attribute
would be use to drive the GUI, not the media tools. Therefore, you do
not get media clipping. You would get an unsynchronized GUI for a
typically very short period of time.

And to me, being able to signal to the other end that you will not be
sending media for a while seems useful. The video example I wrote in the
draft illustrates this point.

Thanks,

Gonzalo
_______________________________________________
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
Paul Kyzivat | 3 Dec 2002 15:57
Picon
Favicon

Re: Re: Early media: a summary

Gonzalo,

Following this logic, a recipient that has negotiated 'inactive' for the media stream, and who has also
received a=intention:nosend, is still expected to receive media over the connection and render it.

In your video example, if the video window is minimized when no video is expected, you will still get 'video
clipping. 

An analogous audio example would be if you normally play music on your pc via a media player application.
When your softphone has negotiated a media stream that expects to receive audio, it then grabs the audio
device from the media player and uses it to render incoming audio over the media stream. Whenever the
stream is not expected to receive audio, the device is handed back to the media player. This also would
result in clipping if audio is received over a media stream where incoming audio has not been negotiated.

As someone else mentioned on this thread, fixing clipping by handling received media on a stream that isn't
expected to receive media may also be inconsistent with the intended semantics of 'inactive' in the midst
of a media session. 

If these changes are made, what is the purpose of the directionality attributes? Are they simply a request
of the form "could you help me out by being quiet for awhile?", that is not in any way binding? And then, is the
intention attribute simply a way of saying "No, I intend to talk even though you don't want me to?", which is
itself optional because you can talk without saying it and the recipient is still expected to render what
you send?

This seems very wrong.

It is important to get this clarified. It makes a big difference in the way I implement a media stream. Am I
*required* to read from a stream that is inactive, to ensure that unexpected media doesn't queue up in it?
This isn't such a problem with UDP, but could be a serious problem with media streams sent over TCP. If so,
some may find it preferable to go back to c=0.0.0.0 for inactive streams.
(Continue reading)

Permalink | Reply | 1 comment |
headers
William Marshall | 3 Dec 2002 16:10
Picon

Re: Early media: a summary

Gonzalo,

I've read through your updated version 00 of the draft, and still have
a number of major concerns with it.

First and foremost, we had a long discussion last summer on this email
list during the last call on the sip-isup draft, leading to consensus
on handling of early media and in-band-ringback.  I see no reason why
the agreements of last summer need to be scrapped in favor of a complete
new mechanism,  If there is some cruical flaw in the solution contained
in draft-ietf-sipping-isup-06, please describe it.

Second, I believe the only real use of early media, as you have defined it
in section 1, is for interworking with legacy systems, particularly the
PSTN.  Numerous complex issues (which are not addressed in your draft)
of e.g. early-media-on-hold, call-transfer of early media, etc, lead me
to believe the concept should not be encouraged for SIP-SIP connections.
And if the only real use is for interworking with the PSTN, again the
proper place for the definition of how it is done is the sip-isup draft.
(A SIP endpoint that wants to act like the PSTN can follow those rules too).

Media clipping is certainly a real problem, and needs to be addressed.  
But your "early media" definition in Section 1 is "from the moment the 
initial INVITE is sent until the UAS generates a final response".  The
clipping problems occur between the UAS generating the final response and
the UAC processing it.  Your new "a=intention" does nothing to solve
the problem.  And section 6.2 should only be given as a bad example that 
should not be followed, since the additional offer/answer exchange after 
pickup will guarantee clipping.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gonzalo Camarillo | 3 Dec 2002 16:17
Picon
Picon

Re: Re: Early media: a summary

Paul,

there are two transitions in the GUI when a sender stops sending media
for a while:

1) The sender stops sending media: this can be signalled with the
intention attribute. This way the receiver can distinguish this
situation from a network dropping packets.

2) The sender resumes sending media: this time SIP will not help you,
because your media packets may arrive before your SIP signalling to the
receiver. Therefore, the receiver must listen to the media.

Therefore, the intention attribute resolves the first bullet. The second
bullet cannot be resolved with SIP. Now, we should see if it is
worthwhile resolving the first bullet or not.

I claim that it is worthwhile resolving it, because in many situations I
want the other end to know that I am not sending media for a while
(intention attribute), but I want him to know that media may resume at
any point in time (SDP direction attribute). In the video example, the
receiver will have to be ready to maximize the window as soon as media
resumes.

What is your opinion on this matter? Do you find useful resolving bullet
1? The other option is let the receiver think that either the sender is
not sending anything or that the network is dropping packets. This may
not usually be a problem with audio, but with video the receiver will
typically freeze the last image received -> bad user experience.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gonzalo Camarillo | 3 Dec 2002 16:23
Picon
Picon

Re: Early media: a summary

Bill,

inline:

William Marshall wrote:
> 
> Gonzalo,
> 
> I've read through your updated version 00 of the draft, and still have
> a number of major concerns with it.
> 
> First and foremost, we had a long discussion last summer on this email
> list during the last call on the sip-isup draft, leading to consensus
> on handling of early media and in-band-ringback.  I see no reason why
> the agreements of last summer need to be scrapped in favor of a complete
> new mechanism,  If there is some cruical flaw in the solution contained
> in draft-ietf-sipping-isup-06, please describe it.

That draft says that the early media solution described is a "simple"
one. We already anticipated at that point in time that a fully-featured
early media solution was in its way.

>
> Second, I believe the only real use of early media, as you have defined it
> in section 1, is for interworking with legacy systems, particularly the
> PSTN.  Numerous complex issues (which are not addressed in your draft)
> of e.g. early-media-on-hold, call-transfer of early media, etc, lead me
> to believe the concept should not be encouraged for SIP-SIP connections.
> And if the only real use is for interworking with the PSTN, again the
> proper place for the definition of how it is done is the sip-isup draft.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane