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

["Christer Holmberg (JO/LMF)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]On Behalf Of Paul
> Kyzivat
> Sent: 25. maaliskuuta 2004 16:36
> To: Steve Langstaff
> Cc: Jonathan Rosenberg; Alex Bligh; [e-mail]
> 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
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

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.


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