Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE

From: [email-masked]
Date: Fri, 19 Mar 2004 07:36:38 +1100

Alex,
        This email thread starting with an implementors query on session 
refresh for billing (yes again) but now has a life of it's own!. Again, no 
expert here but RTP / RTCP are a port pair (sorry my bad terminology) RTCP 
will continue to be sent even with mute / silence suppression for one or 
both parties - is it enough for a FW that it knows to keep an RTP port 
open when it continues to receive RTCP packets for the corresponding port 
pair ?. Which came from detection on a UA for presence of RTCP is 
prefereble to detection of RTP for determining if a session is still 
active.

Regards,

Wayne Davies
email:   [email-masked]

Alex Bligh <[email-masked]>
Sent by: [email-masked]
19/03/2004 07:22 AM
Please respond to Alex Bligh

        To:     [email-masked]
        cc:     Alex Bligh <[email-masked]>
        Subject:        [Sip] Keepalive on media protocols while mute / on-hold etc, & SIP INVITE

100% of the 2(!) vendors I have tested do not appear to send any media
stream packets unidirectionally (when one end is muted) or bidirectionally
(re-invite when other party put on hold by UA). This appears not to be in
conflict with any standard. However, I feel (perhaps incorrectly) a media
keepalive would be useful so intervening NAT/f/w stuff stays open. Clearly
this is simple in the mute case (as the muted device can just send 
whatever
it likes when it likes), but how about in the re-invite case where the UA
appears to be being told "no I don't want a media stream". Is there some
way of saying "but I have to send you a very small keepalive media stream
or the transient entry in my stateful mid-device will disappear, and 
please
don't send me port-unreachables either"?

The other reason this would be useful is it would allow UAs (including
media gateways) to reliably respond to lack of media stream (RTP etc.) and
shut down a hanging SIP session - from what I can see with the UAs I'm
looking at, one side putting the other on hold, or both ends being on 
mute,
is going to tear down a SIP session if this sort of switch is enabled
without keepalives.

Alex

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

******************************************************************************
 - NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged information.  If you have received this email in error, please notify the sender and delete it immediately.

Internet communications are not secure. You should scan this message and any attachments for viruses.  Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
******************************************************************************

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 25 Mar 2004 15:53:03 +0100

Hi,

This the following is obvious, I guess, but just to point it out:

If a stream is removed (ie not only put on hold), no RTP and no RTCP will be sent, and possible fw/nat holes may be closed. Now, since we don't have a media stream I guess that is ok (we should of course be able to open a new hole if a new stream is added), and in this case no BYE would be sent (since the signalling session is still open).

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Paul
> Kyzivat
> Sent: 25. maaliskuuta 2004 16:36
> To: Steve Langstaff
> Cc: Jonathan Rosenberg; Alex Bligh; [email-masked]
> Subject: Re: [Sip] Keepalive on media protocols while mute / on-hold
> etc, & SIP INVITE
> 
> 
> 
> 
> Steve Langstaff wrote:
> > 
> > Could sendonly/recvonly/inactive be modified so that they 
> (can) periodically send no-op or CNG payloads to keep the 
> NAT/Firewall happy, or do these RTP states preclude the 
> sending of ANY RTP? 
> 
> Of course they *could* be modified to permit this. But more would be 
> needed - to negotiate whether they *should* periodically send no-ops.
> 
> The alternative Jonathan proposed:
> 
> >>Another option is ICE, which uses STUN to do connectivity 
> checks. It 
> >>makes sense to continue those checks during the session, for the 
> >>purposes of keeping the bindings active, and checking, in 
> fact, that 
> >>they have not changed. The benefit here is that you can 
> still signal 
> >>hold using sendonly/sendrecv/inactive; the checks using ICE 
> >>would occur 
> >>no matter what the value of these attributes.
> >>
> >>Currently, ICE doesnt do mid-session keepalives, but that is 
> >>easily changed.
> 
> amounts to the same thing using a different sort of no-op, 
> and different 
> notation in SDP to negotiate it. If the problem is NATs, and ICE is 
> needed anyway for NATs, then this may be attractive.
> 
> In addition to changing ICE, this would also require further 
> changes to 
> RTP implementations to deal with mid-session ice messages.
> 
> 	Paul
> 
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "Steve Langstaff" <[email-masked]>
Date: Fri, 26 Mar 2004 16:48:39 -0000

Embedded.

--
Steve Langstaff.

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 25 March 2004 14:36
> To: Steve Langstaff

Would it need extra negotiation?

A "NAT-friendly" RTP implementation could periodically send no-ops or silence (depending on the payload types already negotiated) if it is not sending anything else - or is this outlawed by being set to "recvonly" or "inactive"?

I suppose that it would not work for all firewalls in all situations, but I doubt that the signalling endpoints would be in any better a position to know what session timeout parameters the firewalls were using anyway?