Re: [sipcore] Reviewers needed for new music-on-hold technique

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:[e-mail]] 
> Sent: 18 August 2011 19:11
> To: Elwell, John; [e-mail]
> Subject: RE: Reviewers needed for new music-on-hold technique
> 
> > From: Elwell, John [[e-mail]]
> > 
> > Yes, it does now make an appropriate mention of RTCP - thanks.
> 
> Good -- Thanks for checking that out.
> 
> > I am also curious as to why there are a couple of mentions of using
> > directionality "inactive". Why would any of the entities 
> involved use
> > "inactive" unless they don't wish to send/receive music-on-hold? In
> > particular, why would the INVITE from the executing UA to the MOH
> > source use "inactive" - it is specifically asking the MOH source to
> > send music, so if it wants "inactive", why send the INVITE?
> 
> The strict answer as to why "inactive" is mentioned is that the
> algorithm would not be correct without it, and I hadn't considered the
> possible optimization of omitting the INVITE to the MOH source.
> 
> The situation arises when the remote UA gives directionality
> "sendonly" because the remote UA has previously put the call on hold
> also.  (The remote UA may reduce the directionality to "inactive" due
> to the +sip.rendering="no" in the re-INVITE from the executing UA.)
> 
> There probably other situations where this arises.  E.g., where the
> remote UA has formerly used a media stream in the dialog but no longer
> wants to.
> 
> If all of the media streams that would be in the INVITE to the MOH
> source have "inactive" directionality, the executing UA can omit
> establishing the dialog with the MOH source.  The executing UA would
> synthesize the SDP answer itself.  While the call is on hold, if the
> remote UA sends a re-INVITE with directionality "active"/"recvonly",
> then the executing UA has to start a dialog with the MOH source.
> 
> I should add a note that discusses this optimization.
> 
> > Perhaps this is to do with multiple media, where the remote 
> UA offers
> > several media, and MOH is required only for one of these, 
> so the other
> > media descriptions are set to "inactive" in the INVITE to the MOH
> > source. Whether or not that was the intention of "inactive", I think
> > further discussion of multi-media situations is required. 
> For example,
> > if the remote UA offers audio and video and the executing 
> UA wants MOH
> > only for audio, how would it behave? Perhaps the example should be
> > extended to show such a possibility.
> 
> I would expect multiple media streams to work exactly as an extension
> of the single media stream situation.  But there may be requirements
> that I am not considering.
> 
> In the case where a call is being put on-hold and the remote UA is
> willing to accept two streams (e.g., audio and video), I would expect
> the executing UA to forward this request intact to the MOH server.
> The MOH server would decide what media to send to the remote UA.
> 
> If the executing UA wanted to restrict the MOH media, it could do so
> by editing the SDP offer.  But I don't see any particular reason to do
> so.
> 
> What are the complexities you are seeing?
[JRE] Nothing that can't be dealt with relatively easily, but perhaps some mention is needed. Don't forget that hold (in terms of SDP directionality indications) can be on a per medium basis. I guess if the remote UA offers audio and video and the executing UA only wants to hold audio, it would need to manipulate the SDP such that only audio is offered to the MOH source, and then when the answer is received, add in its own video description before forwarding the answer to the remote UA. Or if the executing UA forwards both audio and video to the MOH source and the MOH source rejects video, the executing UA might want to send inactive to the remote UA rather than passing on the rejection.

John


John Elwell
Tel: [phone] (office and mobile)
Email: [e-mail]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.


> 
> Dale
>