headers
Francois Audet | 1 Apr 2003 03:54

RE: New version of the early media draft



> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield <at> acmepacket.com]
> Sent: Saturday, March 29, 2003 07:43
> To: sipping <at> ietf.org
> Subject: Re: [Sipping] New version of the early media draft
>
> BTW, I do support your position that no additional indication
> of the presence or absence of early media is required in SIP
> signaling. If UAC receives media, it should play it.


This is actually the biggest problem I personnally have with the assumptions on early
media.

I do not think that this rule of "play media when you receive it" is implementable
generally, but only in a few very selected cases.

There are a number of scenarios that I think are problematic:

1 - 180 with SDP

If a 180 is sent with an SDP (for the purpose of telling the far end what
codec is picked), the called UA the shouldn't be sending silence in
RTP because, according to the current rules, the calling UA would stop the
locally generated ringing to play the silence packet. (Doing some heavy duty
DSP parsing to detect if the media is silence or not seems hardly efficient,
nor reliable).

A side effect of this is that if there is a NAT/Firewall involved, it is quite
possible that the binding will expire and the address in the SDP will be invalid
or the media will be blocked upon answer.

If an indication was present to indicate if the in-band media was meant to be
replacing the locally generated tone, we wouldn't have this problem (i.e., one
could send packets in-band to keep the binding alive).
 

2 - Sequential calling

In a sequential calling scenario such as call call forwarding no answer (section 2.8
of the SIP services examples Internet Draft). Suppose the following:

   Alice            Proxy         User B1             User B2
          |                |              |                   |
          |    INVITE F1   |              |                   |
          |--------------->|   INVITE F2  |                   |
          |(100 Trying) F3 |------------->|                   |
          |<---------------|183 ProgressF4|                   |  SDP is included with 183
          | 183 Progress F5|<-------------|                   |
          |<---------------|              |                   |
          |   Both way RTP Established    |                   |
In-band   |<=============================>|                   |
ringing   |                 Request Timeout                   |
          |                |              |                   |
          |                |   CANCEL F6  |                   |
          |                |------------->|                   |
          |                |   200 OK F7  |                   |
          |                |<-------------|                   |
          |                |     487 F8   |                   |
          |                |<-------------|                   |
          |                |     ACK F9   |                   |
          |                |------------->|                   |
          |                |              |    INVITE F10     |
          |                |--------------------------------->|
          |                |              | 180 Ringing F11   |
          | 180 Ringing F12|<---------------------------------|
          |<---------------|              |                   |

The problem with this scenario is that presumably, upon receipt of 180,
the UA needs to figure out somehow that it should be playing the locally
generated alerting. This would imply that upon receipt of the 180, the calling
UA would start a timer and wait until it expires to play the locally generate
tone. Since ringing is composed of tone-silence-tone, the timer will have to be
relatively long. While the UA can detect that the 180 is a different dialog than
the 183, it can not know for sure that the first dialog had been cancelled
because it could be forking: it has to rely on the media.

While this is technically feasible, it imposes a big unecessary burden on
the client, especially if it is a thin client. On a "decomposed" architecture
(like a stimulus MGCP phone), it makes for pretty nasty signalling, if possible
at all.

PS: I'm not saying that the in-band media is necessarily useful in this scenario. I'm
just pointing out the difficulties of the "play media when received" mantra.

3 - Forking

As expected, this is the worst.

   Alice            Proxy         User B1             User B2
          |                |              |                   |
          |    INVITE F1   |              |                   |
          |--------------->|   INVITE F2  |                   |
          |(100 Trying) F3 |------------->|                   |
          |<---------------|183 ProgressF4|                   |  SDP is included with 183
          | 183 Progress F5|<-------------|                   |
          |<---------------|              |                   |
          |   Both way RTP Established    |                   |
In-band   |<=============================>|                   |
ringing   |                |              |                   |
          |                |              |    INVITE F10     |
          |                |--------------------------------->|
          |                |              | 180 Ringing F11   |
Locally   | 180 Ringing F12|<---------------------------------|
generated |<---------------|              |      200 OK F13   |
ringing   |                |<---------------------------------|

There are of course multiple permutations, such as 2 183s, 2 180s, 1 183 followed
by a 180, or 1 180 followed by a 183. And then there might be more than 2 UAs being
forked-to, so the problem can be really bad.

There is no way to associate a specific RTP stream with a specific dialog. The current
draft hints that one UA could randomly play one stream and mute the others (which will be
very troublesome if the other UA doesn't support UPDATE). This is not satisfactory and
would result in garbage being played to the user. For this reason, I believe that the only
reasonable approach in this scenario is to let the 180 override the 183s (if there is
a 180) and ignore all media. This will of course result that there might be some level of
clipping on answer (I have yet to see a network where this is a problem). If there is no
180, one could play one of the random stream (although I don't think it is particulary
useful), or play some default "progress" tone that would indicate to the user that the
call is forked.

One of the reason I think the 180 indication is more useful than the 183-with-in-band-
media is that if the in-band from the 183 is saying "This number has been disconnected,
please hangup" and then a 200 OK comes back (for the 180) wich connects the call, the user
will be very disoriented (realistically, he will probably have hung-up anyways). The other
way around (playing the local ringback) will at least keep the user on-line in case somebody
does answer. The point is that since we can't associate a particular media stream with
the SIP signalling, we can't just "play the media" when there is multiple dialogs.

Many people seem to think that "this is forking, it is trouble, don't use it, bla bla bla".
Unfortunately, it is extremely useful. Also, it happens all the time today when parallel
calling is done (different names exists for it, including "multiple appearances", or
"parallel hunt groups"). If SIP can not properly ring multiple agents in a pool in parallel,
it won't be terribly useful.

The only alternative is to wait for the 200 OK to connect media. Despite the claims of
this introducing clipping on answer, I haven't seen this to be a problem on existing VoIP
systems (i.e., the time it takes the human to answer is longer than the interval during
which there could be clipping). 

One added difficulty is that from the calling UA's perspective, we can't distinguish easily
between case 2 and 3.

---------

My conclusion is that when there are multiple dialogs, we can not honor media at the
calling UA and have to rely on the SIP provisional responses exclusively. This goes against
the "play media as soon as you receive it" principle.

Also, since parallel calling (i.e., forking) is extremely common in call centers and
within enterprises, it greatly limits the applicability of early media, or indeed ringing
2 phones in a private residence. My personal opinion is that it is really limited to TDM
gateway interworking, and only when there is no forking involved or multiple dialog
involved.

Again, I don't believe that the "in-band alerting" indication necessarily solves this (although
it does help in a few cases). I'm just pointing out that the play in-band RTP even if 180 is
received is not generally a good idea. The reason I am sending this email in the context
of this discussion on the in-band ringing indication is that this idea that playing in-band
media automatically helps keeps on re-surfacing.


François Audet

Permalink | Reply | 9 comments |
headers
Gonzalo Camarillo | 1 Apr 2003 07:33
Picon
Picon

Re: New version of the early media draft

Francois,

you must play the media you get because of the 200 OK-RTP race
condition. Therefore, your proposal of sending a 180 response saying "I
will send you media, but do not play it", will cause media clipping when
the 200 OK arrives later than the first RTP packets.

I would like people to note that this problem is unsolvable as long as
SIP and RTP follow different paths (as it is the case). Therefore, no
matter how many flags we define, the 200 OK-RTP race condition will
force us to listen to the media path in order to avoid media clipping.

Gonzalo

Francois Audet wrote:
> 
> > -----Original Message-----
> > From: Bob Penfield [mailto:bpenfield <at> acmepacket.com]
> > Sent: Saturday, March 29, 2003 07:43
> > To: sipping <at> ietf.org
> > Subject: Re: [Sipping] New version of the early media draft
> >
> > BTW, I do support your position that no additional indication
> > of the presence or absence of early media is required in SIP
> > signaling. If UAC receives media, it should play it.
> 
> This is actually the biggest problem I personnally have with the
> assumptions on early
> media.
> 
> I do not think that this rule of "play media when you receive it" is
> implementable
> generally, but only in a few very selected cases.
> 
> There are a number of scenarios that I think are problematic:
> 
> 1 - 180 with SDP
> 
> If a 180 is sent with an SDP (for the purpose of telling the far end
> what
> codec is picked), the called UA the shouldn't be sending silence in
> RTP because, according to the current rules, the calling UA would stop
> the
> locally generated ringing to play the silence packet. (Doing some
> heavy duty
> DSP parsing to detect if the media is silence or not seems hardly
> efficient,
> nor reliable).
> 
> A side effect of this is that if there is a NAT/Firewall involved, it
> is quite
> possible that the binding will expire and the address in the SDP will
> be invalid
> or the media will be blocked upon answer.
> 
> If an indication was present to indicate if the in-band media was
> meant to be
> replacing the locally generated tone, we wouldn't have this problem
> (i.e., one
> could send packets in-band to keep the binding alive).
> 
> 
> 2 - Sequential calling
> 
> In a sequential calling scenario such as call call forwarding no
> answer (section 2.8
> of the SIP services examples Internet Draft). Suppose the following:
> 
>    Alice            Proxy         User B1             User B2
>           |                |              |                   |
>           |    INVITE F1   |              |                   |
>           |--------------->|   INVITE F2  |                   |
>           |(100 Trying) F3 |------------->|                   |
>           |<---------------|183 ProgressF4|                   |  SDP
> is included with 183
>           | 183 Progress F5|<-------------|                   |
>           |<---------------|              |                   |
>           |   Both way RTP Established    |                   |
> In-band   |<=============================>|                   |
> ringing   |                 Request Timeout                   |
>           |                |              |                   |
>           |                |   CANCEL F6  |                   |
>           |                |------------->|                   |
>           |                |   200 OK F7  |                   |
>           |                |<-------------|                   |
>           |                |     487 F8   |                   |
>           |                |<-------------|                   |
>           |                |     ACK F9   |                   |
>           |                |------------->|                   |
>           |                |              |    INVITE F10     |
>           |                |--------------------------------->|
>           |                |              | 180 Ringing F11   |
>           | 180 Ringing F12|<---------------------------------|
>           |<---------------|              |                   |
> 
> The problem with this scenario is that presumably, upon receipt of
> 180,
> the UA needs to figure out somehow that it should be playing the
> locally
> generated alerting. This would imply that upon receipt of the 180, the
> calling
> UA would start a timer and wait until it expires to play the locally
> generate
> tone. Since ringing is composed of tone-silence-tone, the timer will
> have to be
> relatively long. While the UA can detect that the 180 is a different
> dialog than
> the 183, it can not know for sure that the first dialog had been
> cancelled
> because it could be forking: it has to rely on the media.
> 
> While this is technically feasible, it imposes a big unecessary burden
> on
> the client, especially if it is a thin client. On a "decomposed"
> architecture
> (like a stimulus MGCP phone), it makes for pretty nasty signalling, if
> possible
> at all.
> 
> PS: I'm not saying that the in-band media is necessarily useful in
> this scenario. I'm
> just pointing out the difficulties of the "play media when received"
> mantra.
> 
> 3 - Forking
> 
> As expected, this is the worst.
> 
>    Alice            Proxy         User B1             User B2
>           |                |              |                   |
>           |    INVITE F1   |              |                   |
>           |--------------->|   INVITE F2  |                   |
>           |(100 Trying) F3 |------------->|                   |
>           |<---------------|183 ProgressF4|                   |  SDP
> is included with 183
>           | 183 Progress F5|<-------------|                   |
>           |<---------------|              |                   |
>           |   Both way RTP Established    |                   |
> In-band   |<=============================>|                   |
> ringing   |                |              |                   |
>           |                |              |    INVITE F10     |
>           |                |--------------------------------->|
>           |                |              | 180 Ringing F11   |
> Locally   | 180 Ringing F12|<---------------------------------|
> generated |<---------------|              |      200 OK F13   |
> ringing   |                |<---------------------------------|
> 
> There are of course multiple permutations, such as 2 183s, 2 180s, 1
> 183 followed
> by a 180, or 1 180 followed by a 183. And then there might be more
> than 2 UAs being
> forked-to, so the problem can be really bad.
> 
> There is no way to associate a specific RTP stream with a specific
> dialog. The current
> draft hints that one UA could randomly play one stream and mute the
> others (which will be
> very troublesome if the other UA doesn't support UPDATE). This is not
> satisfactory and
> would result in garbage being played to the user. For this reason, I
> believe that the only
> reasonable approach in this scenario is to let the 180 override the
> 183s (if there is
> a 180) and ignore all media. This will of course result that there
> might be some level of
> clipping on answer (I have yet to see a network where this is a
> problem). If there is no
> 180, one could play one of the random stream (although I don't think
> it is particulary
> useful), or play some default "progress" tone that would indicate to
> the user that the
> call is forked.
> 
> One of the reason I think the 180 indication is more useful than the
> 183-with-in-band-
> media is that if the in-band from the 183 is saying "This number has
> been disconnected,
> please hangup" and then a 200 OK comes back (for the 180) wich
> connects the call, the user
> will be very disoriented (realistically, he will probably have hung-up
> anyways). The other
> way around (playing the local ringback) will at least keep the user
> on-line in case somebody
> does answer. The point is that since we can't associate a particular
> media stream with
> the SIP signalling, we can't just "play the media" when there is
> multiple dialogs.
> 
> Many people seem to think that "this is forking, it is trouble, don't
> use it, bla bla bla".
> Unfortunately, it is extremely useful. Also, it happens all the time
> today when parallel
> calling is done (different names exists for it, including "multiple
> appearances", or
> "parallel hunt groups"). If SIP can not properly ring multiple agents
> in a pool in parallel,
> it won't be terribly useful.
> 
> The only alternative is to wait for the 200 OK to connect media.
> Despite the claims of
> this introducing clipping on answer, I haven't seen this to be a
> problem on existing VoIP
> systems (i.e., the time it takes the human to answer is longer than
> the interval during
> which there could be clipping).
> 
> One added difficulty is that from the calling UA's perspective, we
> can't distinguish easily
> between case 2 and 3.
> 
> ---------
> 
> My conclusion is that when there are multiple dialogs, we can not
> honor media at the
> calling UA and have to rely on the SIP provisional responses
> exclusively. This goes against
> the "play media as soon as you receive it" principle.
> 
> Also, since parallel calling (i.e., forking) is extremely common in
> call centers and
> within enterprises, it greatly limits the applicability of early
> media, or indeed ringing
> 2 phones in a private residence. My personal opinion is that it is
> really limited to TDM
> gateway interworking, and only when there is no forking involved or
> multiple dialog
> involved.
> 
> Again, I don't believe that the "in-band alerting" indication
> necessarily solves this (although
> it does help in a few cases). I'm just pointing out that the play
> in-band RTP even if 180 is
> received is not generally a good idea. The reason I am sending this
> email in the context
> of this discussion on the in-band ringing indication is that this idea
> that playing in-band
> media automatically helps keeps on re-surfacing.
> 
> François Audet

--

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo <at> ericsson.com
Finland                   http://www.hut.fi/~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 | 8 comments |
headers
simon issa | 1 Apr 2003 08:50
Picon
Favicon

sip/simple

hii,
i am a 5th year telecom engineering undergraduate, and i have chosen my 
project to be on sip/simple_instant_messaging,but unfortunately i haven't 
find a good book dealing with this issue.
So I'd like to have ,if i may, tutorials about the Instant Messaging with 
SIP,SIMPLE.
Thanks in advance .
Yours Sincerely....

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

_______________________________________________
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 |
headers
Gonzalo Camarillo | 1 Apr 2003 09:28
Picon
Picon

Re: Early media; a summary after the IETF

Tom,

yes, this was mentioned in the meeting.

In any event, it is important that H.248 supports this type of message 
(generate ringback until media arrives), since it is needed regardless 
of any new flags or extensions that we could come up with. It would be 
good if somebody could work on that.

Thanks,

Gonzalo

Tom Taylor wrote:
> Your charts do not reflect an important difference between MGCP and 
> Megaco/H.248. In MGCP, it is possible to tell the MG to automatically 
> terminate application of ringing tone upon detection of incoming media.  
> In Megaco/H.248, the media event is detected on one termination, but the 
> ringing tone is being applied to another.  This means that the MG has to 
> report media detection to the MGC, and then the MGC has to request that 
> ringing tone application be stopped.  It has occurred to me upon 
> reflection that there might be a way around this, but for the moment 
> that is the case.
> 
> Gonzalo Camarillo wrote:
> 
>> Folks,
>>
>> here you have a summary of what happened in the IETF regarding early
>> media.
>>
>> We planned to have an ad-hoc meeting, but since we managed to get more
>> meeting time than expected for this issue and some of the persons
>> involved in the mailing list discussions were not available for an
>> ad-hoc meeting (some of them were not even in San Francisco), we did not
>> finally have the ad-hoc.
>>
>> Regarding the discussions during the second SIPPING session, the main
>> input was slide number 3 of
>>
>> http://www.softarmor.com/sipping/meets/ietf56/slides/Gonzalo-sipping-early-media.ppt 
>>
>>
>> That slide does not discuss the encoding issue. It focuses on the
>> requirements or the gains that adding a SIP "there is media coming" (or
>> "don't generate local ringback") indication would bring.
>>
>> The conclusion of that slide is that a message with "generate local
>> ringback until media arrives" should be provided by the protocol (e.g.,
>> MGCP or H.248) between the MG and the MGC **REGARDLESS** of whether or
>> not we create a "there is media coming" flag.
>>
>> Therefore, assuming that the MG is in accept-media state as soon as the
>> INVITE is sent, the only gain that a "there is media coming" would bring
>> would be saving one message from the MGC to the MG every time a 180 with
>> a flag is received. The gain is zero for 180 responses without the flag.
>>
>> The question is: are people after this optimization (saving of one
>> message in some circumstances) or there is somebody with something else
>> in mind?
>>
>>
>> In any event, the conclusion of the meeting was that I will be gathering
>> use cases where a "there is media coming" flag would be useful. Please,
>> send any use case you have in mind and I will compile them in a
>> document. We hope that such a document help us figure out which
>> requirement is missing.
>>
>> We also may organize a conference call in some weeks to further discuss
>> the issue, if needed.
>>
>> 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
>>
> 
> _______________________________________________
> 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
Permalink | Reply | 0 comments |
headers
David.Rio | 1 Apr 2003 09:51
Picon

Comments on 'early media draft' and 'netann draft'

Hello all

At present, there are TWO 'concurrent' drafts that are dealing with 
early media treatments.
I can hardly understand why there are still 2 drafts ; they shoud be merged.
Or at least a part of Eric's document should be moved to Gonzalo document.

- The first from Gonzalo is describing from a general point of view how 
early media buffers
should be played ; without considering why those RTP buffers should be 
submitted.
It is a good approach I think ; more specially from the point of view of 
UAC who do not have
to take care of why it is receiving those RTP buffers.

There is a major discussion around this draft on what priority should be 
given to local ringback
and RTP buffers when 180 message has been received while the distant UAS 
is already
streaming RTP buffers.
Several points to consider :
* the 180 message is 'RINGING'. We do not have to change its meaning. It 
is the message that
must make the remote UAC to ring. Either by playing tone, either by 
showing a popup, ...
We do not have to presume how the user will be alerted.

* Prority should not be given to incoming early RTP buffers unless 
clearly specified by the remote.
It is the default behaviour implemented my most SIP terminals.
SIP and RTP streams are two different links and we have to synchronize 
them. An UAS will
receive an INVITE with an offered SDP, send a 180, initiates a RTP 
stream using the offered SDP,
prepare the answered SDP and send a 200 response.
=> The remote UAC must give priority to local ringback  until it is 
notify to give other priorities (200, 183,...).

The 183 message is clearly available 'to convey information about the 
progress of the call that is not
otherwise classified'. To notify the remote UAC that it should give 
priority to early RTP buffers we
have to override default behaviour by sending a 183 message. Here, the 
content of this message
could be discussed but probably we should use the content of the SDP to 
change priorities
maybe using 'sendonly', 'recvonly' parameters...
If the remote terminal supports it, of course a PrAck message should be 
asked.

Except this discussion point, I approve this document.

- The second draft is from Eric. He is focusing on a specific use case.
Eric is describing how a proxy or a b2b application server should forward an
INVITE to a media server, adding some parameters to ask  him to run media
treatments. Such media treatments could be played before call establishment
or after.
The proxy approach is so easy to implement  that is why I think it must 
be supported
by the solution.
But when you will want to extend this mechanism to make your media 
server to report
DTMF interactivity for example, the application server will have to be 
in b2b mode.

I approve Eric's document.
But several comments :

* Parameters that describe the announcement to be played are submitted 
as request URI
private parameters. The behaviour of SIP proxies whith those parameters 
is not clear :
some of them forward those parameters ; others remove them (e.g. SER). A 
clear position from the
WG is needed. If the proxy should not forward them, then those 
parameters should be submitted
somewhere else.

* 487 code. There is really a need for a such call flow : early media 
treatment and hang up by
a media server without sending 200 OK. It is a normal scenario and in 
now way an existing
ERROR code should be submitted to the UAC. Then, we have to provide a 
solution.
The 487 code seemed a good solution but RFC 3261 says that  it should be 
used only after
a BYE or CANCEL request. Then it should be extended maybe but what about 
existing B2B proxies
and SIP terminals ?
On the other hand, Eric reported that  'we do not want to break 
meaningful forking proxies' ; I
agree with this position.
=> We have to find a concensus on this open point.

- I made some quick tests of early media with two very used SIP 
softphone : eStara and Ubiquity.
None support PrAck message.

* eStara can play early media without problem. It can receive a 183 
message with a SDP.
Then it plays the incoming RTP buffers.
But (of course) it does not support the 487 response and does not detect 
the call has been
hang up. This illustrate the problem raised earlier of the support of 
the 487 message in this
state of existing equipments state machine.

* Ubiquity does not support at all early media.  Impossible to make it 
playing early RTP buffers.

--

-- 
David Rio
Alcatel CIT - Rennes
ASD France
33 2 99 87 47 18

_______________________________________________
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 | 1 comment |
headers
Gonzalo Camarillo | 1 Apr 2003 12:59
Picon
Picon

Re: Comments to draft-ietf-sipping-aaa-reqs-02 WGLC

Aki,

thanks for the detailed comments. I have added most of them to the 
draft. They will appear in the next revision of the draft, which will 
include all the comments received during the currently ongoing WGLC.

Gonzalo

aki.niemi <at> nokia.com wrote:
> Hi,
> 
> Here are a few comments/suggestions:
> 
> - Ch 1.1 on Terminology
> 	* Accounting has a very nice definition in RFC 2975, suggestion is
> 	  to use that, or the one from Diameter base protocol.
> 	* Home AAA server definition is confusing.
> 	* Online/offline accounting definitions might also benefit from RFC 2975
> 	  definition on real time accounting.
> 	* The last four definitions could also be copied from RFC 3261
> 
> - Ch 2, first paragraph; the motivational text doesn't seem really assuring and
> 	begs the question "If a requirement isn't intended to be supported, why
> 	list it?" Perhaps just say that different deployment scenarios may have
> 	a different set of requirements, e.g., a subset of the requirements listed
> 	in the chapter.
> 
> - Ch 2.1.5., I think I understand what is meant here, but the sentence could
> 	be clearer about what it means for a SIP entity to "have" a user. Does it imply
> 	an administration type relationship, like say a registrar or a presence agent?
> 
> - Ch 2.2.2, This should probably be split into two separate requirements. I think
> 	the first sentence is about authentication between the SIP server and 
> 	AAA server, whereas the latter talks about authentication schemes
> 	supported by the SIP-AAA interface. I.e., authentication between the UA and
> 	the SIP server.
> 
> - Ch 2.3.1, The note about CANCEL below the requirment may well be true, but the 
> 	last sentence contradicts with requirement 2.2.1. After all, if the CANCEL 
> 	can't be authenticated, there's no way to determine that the sender is the
> 	one who originally generated the request to be cancelled.
> 
> - Ch 2.3.3, Seems that Req 2.3.2 already at least partly covers this requirement.
> 	Also, may I suggest that the user profile example be separated
> 	from the text describing the requirement, perhaps as a note or a separate
> 	paragraph.
> 
> - Ch 2.3.4, similar to de-authorization, there should also be a requirement about
> 	re-authorization. This would be useful in tasks that require refreshes, such
> 	as registrations and subscriptions.
> 
> - Ch 2.4, first paragraph; I think much of the motivational text could well be 
> 	omitted if the term "accounting" had been properly defined in Ch 1.1.
> 
> - Ch 2.4.1, This seems like a good thing, but it's hard to really understand what
> 	is required. Is it that accounting information is granular? I can imagine this
> 	to be useful not only in session duration but also in other services. 
> 
> - Ch 2.4.2 and 2.4.3, I don't quite understand the meaning of  "direct bearing on".
> 	I'm sure there's a better term to describe the relationship. Perhaps "link" or
> 	"correlation"?
> 
> - Ch 2.4.5, I believe this is a general requirement, and not only relevant to
> 	charging.
> 
> - Ch 2.4.6, This requirement again talks about charging when I don't think it
> 	needs to.
> 
> - Ch 2.4.10, Suggestion is to separate the example from the requirement text. 
> 	Also, the example seems to also talk about authorization based on real-time
> 	accounting data - perhaps a requirement for the Authorization section?
> 
> Cheers,
> Aki 
>   
> _______________________________________________
> 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
> 

--

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo <at> ericsson.com
Finland                   http://www.hut.fi/~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 | 501 comments |
headers
Christer Holmberg | 1 Apr 2003 14:34
Picon
Picon

Re: New version of the early media draft


Hi,

Forking is always going to a problem, and that is part of the issues I have
on the "must play all media you receive" stuff. In forking cases a UAC may
use whatever local policy to decide which media stream will be played to the
user. Of course, the UAC may mix all streams together, and there will be a
risk the user will only hear a mess, but that is local policy, and should
not be required behaviour.

Also, like I said earlier, there are cases where a UAC may not be able, or
may not want to, play media before it receives a remote SDP for that stream.
I think we should at least have an early dialog established before we put
media handling requirements on the nodes - then we can discuss about how UAS
makes decissions related to local ringback etc.

So, therefore I think it is important for a UAS to send his SDP as soon as
possible - NO MATTER if it's sent in 180 or 183, and NO MATTER if he
actually intends to send early media or not (even if the UAS is not going to
send any media before 200 OK, the UAC would still need the SDP before that,
to establish an early dialog, to prevent clipping).

Just my thoughts...

Regards,

Christer Holmberg
Ericsson Finland

Gonzalo Camarillo wrote:

> Francois,
>
> you must play the media you get because of the 200 OK-RTP race
> condition. Therefore, your proposal of sending a 180 response saying "I
> will send you media, but do not play it", will cause media clipping when
> the 200 OK arrives later than the first RTP packets.
>
> I would like people to note that this problem is unsolvable as long as
> SIP and RTP follow different paths (as it is the case). Therefore, no
> matter how many flags we define, the 200 OK-RTP race condition will
> force us to listen to the media path in order to avoid media clipping.
>
> Gonzalo
>
> Francois Audet wrote:
> >
> > > -----Original Message-----
> > > From: Bob Penfield [mailto:bpenfield <at> acmepacket.com]
> > > Sent: Saturday, March 29, 2003 07:43
> > > To: sipping <at> ietf.org
> > > Subject: Re: [Sipping] New version of the early media draft
> > >
> > > BTW, I do support your position that no additional indication
> > > of the presence or absence of early media is required in SIP
> > > signaling. If UAC receives media, it should play it.
> >
> > This is actually the biggest problem I personnally have with the
> > assumptions on early
> > media.
> >
> > I do not think that this rule of "play media when you receive it" is
> > implementable
> > generally, but only in a few very selected cases.
> >
> > There are a number of scenarios that I think are problematic:
> >
> > 1 - 180 with SDP
> >
> > If a 180 is sent with an SDP (for the purpose of telling the far end
> > what
> > codec is picked), the called UA the shouldn't be sending silence in
> > RTP because, according to the current rules, the calling UA would stop
> > the
> > locally generated ringing to play the silence packet. (Doing some
> > heavy duty
> > DSP parsing to detect if the media is silence or not seems hardly
> > efficient,
> > nor reliable).
> >
> > A side effect of this is that if there is a NAT/Firewall involved, it
> > is quite
> > possible that the binding will expire and the address in the SDP will
> > be invalid
> > or the media will be blocked upon answer.
> >
> > If an indication was present to indicate if the in-band media was
> > meant to be
> > replacing the locally generated tone, we wouldn't have this problem
> > (i.e., one
> > could send packets in-band to keep the binding alive).
> >
> >
> > 2 - Sequential calling
> >
> > In a sequential calling scenario such as call call forwarding no
> > answer (section 2.8
> > of the SIP services examples Internet Draft). Suppose the following:
> >
> >    Alice            Proxy         User B1             User B2
> >           |                |              |                   |
> >           |    INVITE F1   |              |                   |
> >           |--------------->|   INVITE F2  |                   |
> >           |(100 Trying) F3 |------------->|                   |
> >           |<---------------|183 ProgressF4|                   |  SDP
> > is included with 183
> >           | 183 Progress F5|<-------------|                   |
> >           |<---------------|              |                   |
> >           |   Both way RTP Established    |                   |
> > In-band   |<=============================>|                   |
> > ringing   |                 Request Timeout                   |
> >           |                |              |                   |
> >           |                |   CANCEL F6  |                   |
> >           |                |------------->|                   |
> >           |                |   200 OK F7  |                   |
> >           |                |<-------------|                   |
> >           |                |     487 F8   |                   |
> >           |                |<-------------|                   |
> >           |                |     ACK F9   |                   |
> >           |                |------------->|                   |
> >           |                |              |    INVITE F10     |
> >           |                |--------------------------------->|
> >           |                |              | 180 Ringing F11   |
> >           | 180 Ringing F12|<---------------------------------|
> >           |<---------------|              |                   |
> >
> > The problem with this scenario is that presumably, upon receipt of
> > 180,
> > the UA needs to figure out somehow that it should be playing the
> > locally
> > generated alerting. This would imply that upon receipt of the 180, the
> > calling
> > UA would start a timer and wait until it expires to play the locally
> > generate
> > tone. Since ringing is composed of tone-silence-tone, the timer will
> > have to be
> > relatively long. While the UA can detect that the 180 is a different
> > dialog than
> > the 183, it can not know for sure that the first dialog had been
> > cancelled
> > because it could be forking: it has to rely on the media.
> >
> > While this is technically feasible, it imposes a big unecessary burden
> > on
> > the client, especially if it is a thin client. On a "decomposed"
> > architecture
> > (like a stimulus MGCP phone), it makes for pretty nasty signalling, if
> > possible
> > at all.
> >
> > PS: I'm not saying that the in-band media is necessarily useful in
> > this scenario. I'm
> > just pointing out the difficulties of the "play media when received"
> > mantra.
> >
> > 3 - Forking
> >
> > As expected, this is the worst.
> >
> >    Alice            Proxy         User B1             User B2
> >           |                |              |                   |
> >           |    INVITE F1   |              |                   |
> >           |--------------->|   INVITE F2  |                   |
> >           |(100 Trying) F3 |------------->|                   |
> >           |<---------------|183 ProgressF4|                   |  SDP
> > is included with 183
> >           | 183 Progress F5|<-------------|                   |
> >           |<---------------|              |                   |
> >           |   Both way RTP Established    |                   |
> > In-band   |<=============================>|                   |
> > ringing   |                |              |                   |
> >           |                |              |    INVITE F10     |
> >           |                |--------------------------------->|
> >           |                |              | 180 Ringing F11   |
> > Locally   | 180 Ringing F12|<---------------------------------|
> > generated |<---------------|              |      200 OK F13   |
> > ringing   |                |<---------------------------------|
> >
> > There are of course multiple permutations, such as 2 183s, 2 180s, 1
> > 183 followed
> > by a 180, or 1 180 followed by a 183. And then there might be more
> > than 2 UAs being
> > forked-to, so the problem can be really bad.
> >
> > There is no way to associate a specific RTP stream with a specific
> > dialog. The current
> > draft hints that one UA could randomly play one stream and mute the
> > others (which will be
> > very troublesome if the other UA doesn't support UPDATE). This is not
> > satisfactory and
> > would result in garbage being played to the user. For this reason, I
> > believe that the only
> > reasonable approach in this scenario is to let the 180 override the
> > 183s (if there is
> > a 180) and ignore all media. This will of course result that there
> > might be some level of
> > clipping on answer (I have yet to see a network where this is a
> > problem). If there is no
> > 180, one could play one of the random stream (although I don't think
> > it is particulary
> > useful), or play some default "progress" tone that would indicate to
> > the user that the
> > call is forked.
> >
> > One of the reason I think the 180 indication is more useful than the
> > 183-with-in-band-
> > media is that if the in-band from the 183 is saying "This number has
> > been disconnected,
> > please hangup" and then a 200 OK comes back (for the 180) wich
> > connects the call, the user
> > will be very disoriented (realistically, he will probably have hung-up
> > anyways). The other
> > way around (playing the local ringback) will at least keep the user
> > on-line in case somebody
> > does answer. The point is that since we can't associate a particular
> > media stream with
> > the SIP signalling, we can't just "play the media" when there is
> > multiple dialogs.
> >
> > Many people seem to think that "this is forking, it is trouble, don't
> > use it, bla bla bla".
> > Unfortunately, it is extremely useful. Also, it happens all the time
> > today when parallel
> > calling is done (different names exists for it, including "multiple
> > appearances", or
> > "parallel hunt groups"). If SIP can not properly ring multiple agents
> > in a pool in parallel,
> > it won't be terribly useful.
> >
> > The only alternative is to wait for the 200 OK to connect media.
> > Despite the claims of
> > this introducing clipping on answer, I haven't seen this to be a
> > problem on existing VoIP
> > systems (i.e., the time it takes the human to answer is longer than
> > the interval during
> > which there could be clipping).
> >
> > One added difficulty is that from the calling UA's perspective, we
> > can't distinguish easily
> > between case 2 and 3.
> >
> > ---------
> >
> > My conclusion is that when there are multiple dialogs, we can not
> > honor media at the
> > calling UA and have to rely on the SIP provisional responses
> > exclusively. This goes against
> > the "play media as soon as you receive it" principle.
> >
> > Also, since parallel calling (i.e., forking) is extremely common in
> > call centers and
> > within enterprises, it greatly limits the applicability of early
> > media, or indeed ringing
> > 2 phones in a private residence. My personal opinion is that it is
> > really limited to TDM
> > gateway interworking, and only when there is no forking involved or
> > multiple dialog
> > involved.
> >
> > Again, I don't believe that the "in-band alerting" indication
> > necessarily solves this (although
> > it does help in a few cases). I'm just pointing out that the play
> > in-band RTP even if 180 is
> > received is not generally a good idea. The reason I am sending this
> > email in the context
> > of this discussion on the in-band ringing indication is that this idea
> > that playing in-band
> > media automatically helps keeps on re-surfacing.
> >
> > François Audet
>
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo <at> ericsson.com
> Finland                   http://www.hut.fi/~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 | 0 comments |
headers
zhigang.c.liu | 1 Apr 2003 15:44
Picon

RE: [rohc] RE: SIGCOMP and large binary content SIP messages

Robert,

>  I don't think it is a problem with SigComp multiplexing, but 
> more like a SIP internal issue. What if there is a TCP stream 
> of SIP messages and the Content-Length header is missing or 
> false? They will screw up the same way with or without 
> SigComp. 

Since TCP is a reliable transport, this only happens for a
mis-behaved SIP sender. But that is not the "multiplexing" problem 
I mentioned below, which happens even "during normal functioning" 
(see below).

> During normal functioning both SIP and SigComp 
> provide their own flow separation mechanism and they work just fine.

I don't think so. That is what I intended to show by the example,
i.e. the issue to "multiplex uncompressed application messages and 
SigComp messages on the same port". One solution, as I mentioned
before, is to require sigcomp receiver has the ability to parse
uncompressed application messages and detect the end. 

(Of course, I saw Carsten's email and I need understand his
point of view, which says there is no such "multiplexing" and
it is not possible and necessary.)

BR,
Zhigang
_______________________________________________
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 |
headers
Ben Campbell | 1 Apr 2003 16:42

RE: Apology for RE: A WinXP patch

Nothing that couldn't be solved with s/mime ;-)

On Mon, 2003-03-31 at 13:05, Dean Willis wrote:
> network asserted From:?
>  
> haha
>  
> --
> Dean
>         -----Original Message-----
>         From: sipping-admin <at> ietf.org [mailto:sipping-admin <at> ietf.org]
>         On Behalf Of Cullen Jennings
>         Sent: Thursday, March 27, 2003 1:12 PM
>         To: sipping <at> ietf.org
>         Subject: Apology for RE: [Sipping] A WinXP patch
>         
>         
>         I did not sent any patches - certainly not to XP :-) Cullen
>         (the guy with the fluffy hair) 
>                 -----Original Message-----
>                 From: sipping-admin <at> ietf.org
>                 [mailto:sipping-admin <at> ietf.org]On Behalf Of fluffy
>                 Sent: Wednesday, March 26, 2003 3:50 PM
>                 To: sipping <at> ietf.org
>                 Subject: [Sipping] A WinXP patch
>                 
>                 
>                 This is a WinXP patch
>                 I expect you would like it. 

_______________________________________________
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 |
headers
Francois Audet | 1 Apr 2003 17:55

RE: New version of the early media draft

Gonzallo,

Just a clarification. I am not proposing that we generally do NOT play the media
if received when a 180 was sent. Indeed we should play it when possible.

I am saying that if there are multiple dialogs (as when there is forking), and
at least one of the forks wants to play early media, we can not play it and have
to wait until answer. The numerous reasons were described in my past email. There
is no forks, or when all the forks are NOT using early media, we could play the
media (that seems to suggest discouraging allowing sending early media with 180,
or at least to have the magic flag discussed earlier).

Finally, I don't think the allege "race" condition is a real problem. I've seen
many implementations where multiple sets are ringing, and there is no perceivable
clipping. There are things that can be done at the UI level to minimize that risk.

If there was perceivable clipping, then SIP wouldn't support call centers, and
simultaneous of multiple lines when one of them does early media. That would be
unacceptable.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo <at> lmf.ericsson.se]
> Sent: Monday, March 31, 2003 21:33
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Bob Penfield'; 'sipping <at> ietf.org'; 'Jon PETERSON
> (Jon.Peterson <at> neustar.com)'; 'Christer Holmberg'
> Subject: Re: [Sipping] New version of the early media draft
>
>
> Francois,
>
> you must play the media you get because of the 200 OK-RTP
> race condition. Therefore, your proposal of sending a 180
> response saying "I will send you media, but do not play it",
> will cause media clipping when the 200 OK arrives later than
> the first RTP packets.
>
> I would like people to note that this problem is unsolvable
> as long as SIP and RTP follow different paths (as it is the
> case). Therefore, no matter how many flags we define, the 200
> OK-RTP race condition will force us to listen to the media
> path in order to avoid media clipping.
>
> Gonzalo

Permalink | Reply | 0 comments |

Gmane