Subject: RE: [Sipping] Some thoughts on fixing early media

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 19 Jul 2006 18:23:13 +0200

Hi Stephen,

As I said in another reply, I think "dropping" 18x responses is bad protocol design. Why can't you PRACK the 18x and still drop RTP packages from IP addresses/ports you don't want to listen to?

Also, how do you "switch" from one early media element to another? As far as I understand the switch is done when you receive 200 (if it comes from another element than the 18x you previously accepted).

Also, you only accept early media based on the FIRST 18x - which may come from an element that is not going to send early media in the first place.

Except from the dropping of 18x messages I am NOT saying you have a bad implementation, but I don't think it's the solution Dean is talking about.

Regards,

Christer

-----Original Message-----
From: Stephen Sprunk [mailto:[email-masked]] 
Sent: 19. heinäkuuta 2006 4:10
To: Dean Willis; Brian Rosen
Cc: 'sipping'
Subject: Re: [Sipping] Some thoughts on fixing early media

Thus spake "Dean Willis" <[email-masked]>
> What would this look like in SIP?
>
> Here's a rough outline. I'm sure somebody can do better. The idea  
> here is to do a "media starts" using provisional reliable messages  
> and a "billing starts" using 200 OK.
>
> I send an INVITE with a new early-media precondition tag. It is  
> forked 4 ways. Each recipient responds with a reliable 18x including  
> an "early-media request" tag,  possibly including an SDP answer (for 
> bidirectional or "early session" media), and possibly including an 
> early-media usage description modifier of some sort.
>
> I pick one of the 4 responses and send a PRACK with an early-media - 
> accepted tag. I defer sending PRACK to the other nodes. The node 
> receiving the PRACK starts sending its early media. Assuming we don't  
> end up moving to a session (with a 200 OK/ACK), somebody CANCELs this  
> leg, and we go on to the next one.
>
> Eventually,  we either set up a session with one of the respondents  
> and CANCEL the remainder, or we time out the prov-rel and they give  
> up, or we end up CANCELing all of the legs and give up ourselves, or  
> some combination thereof.
>
> Crazy, huh?

That's rather similar to what our UAC does today, actually.

1. Send INVITE, which gets forked to N destinations.
2. By default, all incoming RTP is dropped.
3. Up to N destinations reply with 183.
4. We PRACK the first 183 to come in.
5. Send/receive RTP according to that 183's SDP (i.e. ignore RTP coming from any other IP/port) 6. Ignore all other 183s (do not PRACK).
7. When a 200 comes in, we ACK it.  If the 200's SDP is different than the PRACKed 183's SDP, switch to the new SDP.
8. The proxy CANCELs the other legs.

The above has the disadvantage that early media is required to be bidirectional, but for NAT/FW and security reasons we considered that a feature, not a bug.

This seems to work as well as can be expected when forking is used and no other information is available to pick which 183 is "best".  That'd certainly be a nice enhancement, but it's not necessary in the use cases I deal with -- first response seems to work for us.  If others would like to add some sort of indication what type of media a 183 is providing, that may make things easier for other folks.

S 

_______________________________________________
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

_______________________________________________
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: "Stephen Sprunk" <[email-masked]>
Date: Thu, 20 Jul 2006 23:54:06 -0500

Thus spake "Christer Holmberg (JO/LMF)" <[email-masked]>
> As I said in another reply, I think "dropping" 18x responses is bad
> protocol design. Why can't you PRACK the 18x and still drop RTP
> packages from IP addresses/ports you don't want to listen to?

IMHO, it's rude to pretend you're listening to someone's media (or pretend 
you'll send some back) when you have no intention of doing so.  Not PRACKing 
a 18x is the least-evil method we could think of to let someone know we're 
not listening.

> Also, how do you "switch" from one early media element to another?
> As far as I understand the switch is done when you receive 200 (if it
> comes from another element than the 18x you previously accepted).

We take the first 18x and play the early media to/from that leg up until a 
200 is received.  If the 200's SDP is different from the 18x's SDP, we 
change the remote IP/port that the media plane is connected to (in a virtual 
sense).  We can't accept RTP from an unknown sender or multiple senders, so 
we have to pick a single response with SDP for early media to work at all, 
and RTP from any other source is silently dropped.

> Also, you only accept early media based on the FIRST 18x - which
> may come from an element that is not going to send early media in
> the first place.

If the 18x contains SDP (usually 183), we make the assumption they intend to 
send early media.  If you don't intend to send us early media, send us a 18x 
that doesn't include SDP (usually 180).  Very simple.

Now, someone could muck things up by sending us a 183 w/SDP and then not 
send any media, but we've put in a special case to continue local ringback 
until the first incoming RTP packet shows up.  Hacks upon hacks upon 
hacks...

> Except from the dropping of 18x messages I am NOT saying you
> have a bad implementation, but I don't think it's the solution Dean is
> talking about.

I think it's closer to what Dean describes than how it appears people assume 
all UACs work today.  I just wanted to describe what we did as a sort of 
strawman, since it seemed reasonable to us.  Perhaps others can learn from 
it or make improvements (which we'd be happy to implement).

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 20 Jul 2006 23:54:06 -0500

S

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 21 Jul 2006 14:38:00 +0200

Hi, 

>IMHO, it's rude to pretend you're listening to someone's media (or
pretend you'll send some back) when you have no 
>intention of doing so.
>Not PRACKing a 18x is the least-evil method we could think of to let
someone know we're not listening.

I don't know if that is what PRACK means. PRACK only means that you have
received the reliable 18x.

I DO agree it's a mechanism to prevent a UAS from sending media, because
the offer/answer transaction will not terminate - UNLESS the UAS follows
3261 and assume the UAC will accept media as soon as it has sent the
INVITE - no matter if it will receive your 18x/SDP answer or not). But,
it's not a solution I'd like to standardize.

And, as I write below, according to RFC3262 a UAS is not allowed to send
2xx until an 18x with SDP has been pracked.

>We take the first 18x and play the early media to/from that leg up
until a 200 is received.  If the 200's SDP is 
>different from the 18x's SDP, we change the remote IP/port that the
media plane is connected to (in a virtual sense).  We 
>can't accept RTP from an unknown sender or multiple senders, so we have
to pick a single response with SDP for early 
>media to work at all, and RTP from any other source is silently
dropped.

RFC3262 says (eventhough I don't like that rule) that the UAS MUST NOT
send a 2xx in case any of the un-pracked 18x responses contained SDP, so
if the 18x you are not pracking did contain SDP you will never get a 200
from another UAS. 

>>Also, you only accept early media based on the FIRST 18x - which may 
>>come from an element that is not going to send early media in the 
>>first place.
>
>If the 18x contains SDP (usually 183), we make the assumption they
intend to send early media.  If you don't intend to 
>send us early media, send us a 18x that doesn't include SDP (usually
180).  Very simple.

Yes - assuming all other terminals makes the same assumption :)

And, it does prevent multiple offer/answer transactions before 200 OK,
e.g. if you wish to negotiate down to a single codec, or if you
want/need to send security/ICE/whatever related information in the SDP
before 200 OK.

>Now, someone could muck things up by sending us a 183 w/SDP and then
not send any media, but we've put in a special case 
>to continue local ringback until the first incoming RTP packet shows
up.  Hacks upon hacks upon hacks...
>>Except from the dropping of 18x messages I am NOT saying you have a
bad implementation, but I don't think it's the 
>>solution Dean is talking about.
>I think it's closer to what Dean describes than how it appears people
assume all UACs work today.  I just wanted to 
>describe what we did as a sort of strawman, since it seemed reasonable
to us.  Perhaps others can learn from it or make 
>improvements (which we'd be happy to implement).

I think many parts of your solution are ok - I've implemented similar
things myself :) However, the only thing it generically solves is that
media isn't mixed on the UAC side. I does not, for example, allow early
media from multiple UAS entities.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Jul 2006 16:05:43 -0500

On Jul 20, 2006, at 11:54 PM, Stephen Sprunk wrote:

> pretend you'll send some back) when you have no intention of doing  
> so.  Not PRACKing a 18x is the least-evil method we could think of  
> to let someone know we're not listening.
>
> until a 200 is received.  If the 200's SDP is different from the  
> 18x's SDP, we change the remote IP/port that the media plane is  
> connected to (in a virtual sense).  We can't accept RTP from an  
> unknown sender or multiple senders, so we have to pick a single  
> response with SDP for early media to work at all, and RTP from any  
> other source is silently dropped.

This highlights something I always thought was a fundamental design  
flaw in SIP.

You should never have to blindly accept media from an unknown IP  
address and port number.

I've always thought that the "offer" should include information about  
what/where you are sending from, as well as about where you are  
listening and what you're willing to receive.

How does you solution deal with remote nodes that send from a  
different IP address than they listen on? My guess is -- it doesn't.  
Do you also require symmteric RTP (send/receive from the same port)?

--
Dean

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 22 Jul 2006 19:49:52 +0200

Hi,

>This highlights something I always thought was a fundamental design flaw in SIP.
>
>You should never have to blindly accept media from an unknown IP address and port number.
>

It's not only about the IP address and/or port from where you're sending. E.g. for some video codecs I believe you have to include some codec specific sending capabilities in the SDP (attributes have been defined for that) - eventhough the SDP is only supposed to indicate "what you are able to receive"...

>Do you also require symmteric RTP (send/receive from the same port)?

I think that's an assumption one often has to make - not only in this case, but also in other scenarios and environments. And, it doesn't only affect the media, but sometimes also the SIP signalling.
 
Regards,
 
Christer

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 22 Jul 2006 17:32:12 -0500

> listening and what you're willing to receive.

Unfortunately, due to stateful firewalls and NATs, one cannot receive media unless one also sends media, so unidirectional media (early or otherwise) is broken in most cases anyways.

> Do you also require symmteric RTP (send/receive from the same port)?

By default, we require RTP to be symmetric.  We do have compatibility options that allow the port and/or address to be different to achieve interop with certain vendors, but it's rare we need to use them.  Non-symmetric RTP fails in the same scenarios that unidirectional media does, so hacking around to support it at the endpoints is usually futile.

S

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 23 Jul 2006 10:40:32 +0200

> listening and what you're willing to receive.

Unfortunately, due to stateful firewalls and NATs, one cannot receive media 
unless one also sends media, so unidirectional media (early or otherwise) is 
broken in most cases anyways.

[JvB] But such a stream could be low frequency (say 1/20 Hz), empty packets 
right? Looks like the same problem that outbound is solving with STUN, 
except that in case of forking it gets more complicated

Regards,

Jeroen

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 23 Jul 2006 19:44:12 -0500

Thus spake "Jeroen van Bemmel" <[email-masked]>
>> Unfortunately, due to stateful firewalls and NATs, one cannot receive
>> media unless one also sends media, so unidirectional media (early or
>> otherwise) is broken in most cases anyways.
> 
> But such a stream could be low frequency (say 1/20 Hz), empty packets 
> right?

In theory.  The reality is that it's about the same amount of code to do that as it is to get the DSP fired up and sending a full media stream, which may end up sending 1/30Hz packets due to noise and/or silence suppression.  And, if the remote host you've set up bidirectional early media to happens to be the one that ends up accepting the call in the 200, you've already paid the price of getting your AGC, AEC, BNS, VAD, jitter buffers, etc. tuned for the call before it actually started, which leads to fewer user complaints about delayed audio cut-through.

Also, given the number of IVR systems that require bidirectional early media to reach a human, in practice it's suicide in the marketplace not to support it by default.

> Looks like the same problem that outbound is solving with STUN, 

That's quite an understatement.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 23 Jul 2006 19:50:41 -0500

>>pretend you'll send some back) when you have no intention of doing so.
> I don't know if that is what PRACK means. PRACK only means that you
> have received the reliable 18x.

I agree that's not what PRACK means, but, as I said, it's the least-evil method we could come up with.

>> until a 200 is received.  If the 200's SDP is different from the 18x's SDP,
>> we change the remote IP/port that the media plane is connected to (in
>> a virtual sense).  We can't accept RTP from an unknown sender or
>> multiple senders, so we have to pick a single response with SDP for
>> early media to work at all, and RTP from any other source is silently
>> dropped.
> 
> RFC3262 says (eventhough I don't like that rule) that the UAS MUST
> NOT send a 2xx in case any of the un-pracked 18x responses
> contained SDP, so if the 18x you are not pracking did contain SDP you
> will never get a 200 from another UAS. 

Hmm.  Maybe I'm misinterpreting how we handle this, then; in practice, it works.  Or maybe the vendors we're working with ignore that rule...

> media from multiple UAS entities.

We don't have the horsepower available to mix multiple incoming media streams, so we _have to_ pick one and stick with it.  Not that mixing is likely to produce good results anyways; how useful is hearing US and UK ringback mixed together?  Or someone's CRBT mixed with a standard land line ringback?  Forking and early media are fundamentally incompatible.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 23 Jul 2006 19:44:12 -0500

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 23 Jul 2006 19:50:41 -0500

S